SENDING A REPLACEMENT - ACORD LIFE & ANNUITY STANDARDS LIFE REPLACEMENT IMPLEMENTATION GUIDE V

The ACORD XML for Life (XMLife) model provides two basic techniques for sending information between trading partners. The first technique is a Request/Response method whereby a requester sends a ―request‖ transaction to a provider who receives, process and replies back with a ―response‖ transaction – typically containing the requested data or a result if an action was requested.

The second is a ―Transmittal‖ method, which is more typical of a batch send. The sender simply blasts the information to the receiving system, or perhaps creates a file for a recipient and places it in a common location (mailbox, file store, etc.). This is a simpler and more traditional method, so we‘ll describe it first.

6.1 Transmittal Method

A Transmittal contains two basic parts: a content section and an envelope section. The content is what has been discussed thus far, all the details beginning at the <OLifE> level object element on down, including <ProductProfile>, <Party>, and so forth. First focus on the content, the details of your profile. Once you have that down, simply ―wrap‖ those details with the information that follows.

The basic construct of a full TXLife Transmittal is: <TXLife>

[… all the message details, i.e. the ―body‖ of your message] </OLifE>

</TXLifeRequest> </UserAuthRequest> </TXLife>

6.2 Request / Response Method

The second method for sending XML for Life transactions is based on the classic Request/Response method. The transaction is typically (though not always) reversed and the system desiring information (Receiving system) initiates the transaction by sending a ―Request‖. The sending system then ―Responds‖ with the appropriate details, as specified in the initial request.

The Request:

[… all the message details, i.e. the ―body‖ of your message] </OLifE> </TXLifeRequest> </UserAuthRequest> </TXLife> The Response: <TXLife> <UserAuthResponse> <TXLifeResponse> <OLifE>

[… all the message details, i.e. the ―body‖ of your message] </OLifE>

</TXLifeResponse> </UserAuthResponse> </TXLife>

6.3 ACORD TXLife Transactions

There are many different types of ACORD transactions. Transactions have been defined for New Business Submission, Product Inquiry, Address Change and a whole range of life insurance business process transactions (a.k.a. messages). For more details please refer to the ACORD TXLife Implementation Guide, which outlines all the transaction types available and their basic, minimum required construct. Industry Implementation Guides, like this one, add ―flesh-to-the-bones‖ to the basic TXLife guide, describing what a more complete trading partner business message should look like in specific business context.

6.4 Transport and Security

It is important to note that the ACORD XMLife and TXLife specifications do not define how you will physically transport the message, or issues of security. The ACORD standards are by design meant to be neutral on this point, allowing you to adopt whatever mechanisms are appropriate for your business needs.

Typical physical implementation methods have included:

FTP – Using the Internet File Transport Protocol to place an XMLife file on a FTP Server, allowing a client system to retrieve it (via FTP GET Method) at their leisure. This is generally only appropriate for a Transmittal method, since Request/Response implies a real-time communication between sender and receiver.

SMTP – Using Internet Mail protocol to send the file. This has been successfully used by trading partners for both Transmittals as well as Request/Response transactions.

Messaging Middleware – A robust solution, providing security as well as assurance that transactions are received (non-repudiation), error-recover, etc are provided in products like IBM MQSeries or Microsoft Message.

Regardless of the physical transport, The ACORD XMLife/TXLife messages are the same.

6.5 TXLife Transaction Element and Type Code Details

The TXLife ―wrapper‖ provides information about the sender, the recipient, when the message was created and so forth. It does NOT include details about the product profile- that is in the content section beginning with the <OLifE> object.

Following are all the expected fields that you should value and include in a well-formed and valid ACORD TXLife Transmittal.

XML Element Name Type Description

<UserAuthRequest> Object

This object defines the transaction/message information about the user and the system that is sending the message.

<UserLoginName> String User Login name into receiving system, if applicable

<CryptType> String

<Pswd> String User Password, if applicable

<CryptPswd> String

<UserSessionKey> String

<VendorApp> Aggregate

<VendorName> String Sender/creator of this file/stream

<AppName> String Name of system creating product profile (source system)

<AppVer> String Version of system creating product profile

<ProxyVendor> String Name of third party, if there is one, sending or transmitting

this message.

<VendorName String Sender/creator of Product profile name (third party name)

<AppName> String Name of system creating product profile (source system)

<AppVer> String Version of system creating product profile

<TXLifeRequest> Object

This object defines the information about this particular message/transaction.

<TransRefGUID> String Uniquely identifies this transaction. Use a 32-bit GUID

(Globally Unique Identifier).

<TransType tc=‖1201‖> Typecode Transaction type uniquely defines this transaction to the receiving system.

XML Element Name Type Description

<TransExeDate> Date Date and time when this file or feed was created.

<TransExeTime> Time Time when this file or feed was created.

<TransMode> TypeCode

<NoResponseOk tc=―1‖> Boolean

1 = Yes

Indicates if a response is desired or necessary. For a transmittal set to ―1‖ for Yes.

<TestIndicator> Boolean

0 = No 1 = Yes

Indicates whether this is a test or production file/stream.

XML Element Name Type Description

<UserAuthResponse> Object

This object defines the transaction/message information about …

<UserLoginName> String User Login name into receiving system, if applicable

<CryptType> String To be discussed

<Pswd> String User Password, if applicable

<CryptPswd> String

<UserSessionKey> String

<VendorApp> Aggregate

<VendorName> String Sender/creator

<AppName> String Name of system creating product profile (source system)

<AppVer> String Version of system creating product profile

<ProxyVendor> String Name of third party, if there is one, sending or transmitting

this message.

<VendorName String Sender/creator of Product profile name (third party name)

<AppName> String Name of system creating product profile (source system)

<AppVer> String Version of system creating product profile

<TXLifeResponse> Object

This object defines the information about this particular message/transaction.

<TransRefGUID> String Uniquely identifies this transaction. Use a 32-bit GUID

(Globally Unique Identifier).

<TransType tc=‖ ‖> Typecode Transaction type

<TransSubType tc=‖###‖ Typecode

<TransExeDate> Date Date and time when this file or feed was created.

<TransExeTime> Time Time when this file or feed was created.

<TransMode> TypeCode To be discussed

<NoResponseOk tc=―1‖> Boolean

1 = Yes

Indicates if a response is desired or necessary. For a transmittal set to ―1‖ for Yes.

<TestIndicator> Boolean

0 = No 1 = Yes

Indicates whether this is a test or production file/stream. If Test then <TestIndicator>1</TestIndicator>.

6.6 TXLife Examples

A basic example of a TXLife Transmittal wrapper would look like: <TXLife>

<VendorName VendorCode="##">Lincoln National Life</VendorName> <AppName>Annuity Profile App Generator</AppName>

</UserAuthRequest> <TXLifeRequest>

<TransRefGUID>938749384753ea765c87-876432</TransRefGUID> <TransType tc="1201">Product Inquiry Transmittal</TransType> <TransExeDate>2002-05-31T13:47:53-05:00</TransExeDate> <TransExeTime>13:20:10</TransExeTime> <TransMode>

<NoResponseOK tc="1">TRUE</NoResponseOK> <OLifE>

… <!—BEGIN XMLife DATA --> </OLifE>

…

<!—close tags -->

A basic Request/Response Transactions might look like this: <TXLife>

<UserAuthRequest> <UserLoginName/> <Pswd/>

<VendorName VendorCode="##">Lincoln National Life</VendorName> <AppName>Annuity Profile App Generator</AppName>

</UserAuthRequest> <TXLifeRequest>

<TransRefGUID>44wa305sf345-368-93ho643-</TransRefGUID> <TransType tc="120">Product Inquiry</TransType>

<OLifE>

… <!—BEGIN XMLife DATA --> </OLifE>

…

<!—close tags --> <TXLife>

<TXLifeResponse>

<TransRefGUID>44wa305sf345-368-93ho643-</TransRefGUID>  Note the return GUID is same as Request

<TransType tc="120">Product Inquiry</TransType>

<OLifE>

… <!—BEGIN XMLife DATA --> </OLifE>

…

In document ACORD LIFE & ANNUITY STANDARDS LIFE REPLACEMENT IMPLEMENTATION GUIDE V 3.1 JANUARY 2009 (Page 30-35)