Thales - ISO 8583 Interface with Cloud TSP

Confidential information of Thales NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product and related material disclosed herein are only furnished pursuant and subject to the terms and conditions of a duly executed License or Agreement related to this Specification. The only warranties made by Thales , if any, with respect to the products described in this document are set forth in such Licence or Agreement. Thales cannot accept any financial or other responsibility that may be the result of your use of the information or soft ware material, including direct, indirect, special or consequential damages.

You should be careful to ensure that the use of this information and/or software material complies with the laws, rules, and regulations of the jurisdictions with respect to which it is used. All rights reserved. Copyright © 202 1 Thales .

Table of Contents

• Revision status
• Introduction
• Scope
• Audience
• Reference documents
• Communication channel between a remote host and the Cloud TSP
• Structure and Content of Messages
• Overview of the message structure
• Header
• Message type
• Primary Bitmap
• Data Elements Fields attributes
• Data Elements Coding
• List of ISO messages supported
• 1100 – Detokenization request to the Cloud TSP
• 1110 - Detokenization request response from the Cloud TSP
• 1120 - Transaction Advice communication to the Cloud TSP (re-tokenization)
• 1130 - Transaction Advice communication response from the Cloud TSP (re-tokenization)
• List of data elements in ISO messages
• Requests validation by TSP
• TSP Database
  • 1100 - Detokenization request to the Cloud TSP
  • 1120 - Transaction Advice communication to the Cloud TSP (re-tokenization)
• Verification of 1100 - Detokenization request to the Cloud TSP
  • HCE verification flow
  • Secure Element verification flow
  • In-app payment cloud cryptogram verification flow
• Verification of 1120 - Transaction Advice communication to the Cloud TSP (re-tokenization)
• Message Data Elements Description
• Appendix
• Token Assurance Method codification
• Storage Type
• Connectivity Requirements
  • VPN
  • TLS Authentication
  • MAC usage
• MAC Details
• Key Interchange
  • MAC Key
  • MAC
  • Keys type and algorithms
• Healthcheck Interface
• ISO interface
• ISO8583 request/response example

Table List

Table 1 - MESSAGE STRUCTURE Table 2 - MESSAGE HEADER Table 3 - LIST OF ISO MESSAGES SUPPORTED Table 4 - FIELDS PRESENCE IN ISO MESSAGES

Revision status

1 Introduction

The Cloud Token Service Provider is a payment tokenization service providing EMV tokenization or PCI tokenization.

1.1 Scope

The present document describes the format of messages exchanged between Cloud TSP and a remote Host (Acquirer server or Bank server).

1.2 Audience

The audience of this documents is:

* POS aggregators connecting to the detokenization interface of the Cloud TSP service
* Payment systems implementing tokenization

1.3 Reference documents

* BankAxept. Cloud TSP In-app payment cloud cryptogram.

2 Communication channel between a remote host and the Cloud TSP

The communication channel is specific to each project and must established a secure channel (see 8.3 Connectivity Requirements)

The messages exchanged through this interface are based on ISO 8583 norm. Using this norm, the message content formats and length vary according to the message exchanged.

This document provides a description of thes messages (message structure and the data elements contained in these messages).

3 Structure and Content of Messages

3.1 Overview of the message structure

HTTP is used as transport layer for carrying ISO message payload. HTTP header includes a unique transaction ID for a given request and some information related to the payload. HTTP body contains ISO Message Type, Bitmap and Data Elements encoded in base64.

Header format is detailed hereafter in this document.

Payload includes information specified in table below. Each part is detailed in this document.

Table 1: Message Structure

3.2 Header

The header is required in all messages. The header value is 8 bytes length. It has the following format:

Table 2 – Message Header

3.3 Message type

The message type is an element of 4 positions serving to identify the general function of the message. This element is mandatory in all the messages.

The following messages are exchanged between Cloud TSP and the remote Host:

Table 3 – List of ISO messages supported

3.4 Primary Bitmap

The ISO 8583/1993-12-15 uses a messages scheme by bits vector or ‘‘bit maps’’. The bitmap structure indicates the presence or absence of data element (‘1’ inside the bitmap indicates the element is present, while ‘0’ indicates the element is absent). The bytes in the bitmap are numbered from left to right.

The message may support several bitmaps each one has 8 bytes length (64-bit string contained within an eight-byte data element), can be used in the messages exchanged with Cloud TSP.

• A primary bitmap indicates the presence of fields from 1 to 64.
• A secondary bitmap indicates the presence of fields from 65 to 128.

The primary bitmap is required in all the messages. The secondary bitmap is included in the message if at least one field in the interval 65 to 128 is present. The presence of the secondary bitmap is signaled by setting the first bit of the primary bitmap (The leftmost bit) to 1. In the current version of this document the data elements referenced in the secondary bitmap are not used.

Example:

11 00 72 04 66 00 08 61 82 01

11 00 Message type = detokenization request)
72 04 66 00 08 61 82 01 Bitmap
Bitmap in binary
0111 0010 0000 0100    (7204 hex)
0110 0110 0000 0000    (6600 hex)
0000 1000 0110 0001    (0861 hex)
1000 0010 0000 0001    (8201 hex)

Leftmost bit is equal to zero meaning there is a single bitmap.

Then the position of each bit after leftmost bit corresponds to a data element number. The bit value indicates if DE is present (bit=1) or not (bit=0)

3.5 Data Elements Fields attributes

For each Data Element some attributes are specified according to a particular naming described hereafter.

The values below used to represent the data elements type:

The data element containing a data field may have either a fixed length or a variable length.

• Fields with a fixed length are presented by their type followed by the length

Example:

    an-3 means 3 alphanumeric characters (eg: ab8).
    n-5 means 5 digits (eg: 12345).
    b-10 means 10 hexadecimal numbers (eg: F8 A5 07 …etc).

• Fields with a variable length are presented by their type followed by 2 points, followed by the length.

Example:

    an..25 means variable length, up to 25 alphanumeric characters.

The description of the length follows a particular naming as well. The number of digits needed to express the length value in decimal is specified in this document as per example below:

LLVAR = variable length field using 2 digits for length information.
LLLVAR = variable length field using 3 digits for length information.

3.6 Data Elements Coding

Fields with a fixed length:

A length field is not included in ISO message for the field having a fixed length. Only the field value is present in ISO message.

Fields with a variable length:

A field length is included, followed by the field value for data elements with a variable length. The length is coded in hexadecimal on 1 byte. So the maximum value for length is 255. All the data elements in this document are specified as being numeric (type n), alphanumeric (type a, a, and ans) or binary (type b).

Numeric field

This field is bcd encoded. The length is expressed as a number of nibbles (half byte). When the length is an odd value, the leftmost nible must be ignored. It is used only for padding and equal to zero.

Example:

Field n° 02 – Primary Account Number
Attribute: n..19
Coding: 11 01 23 45 67 89 01 23 45 67
Length: 11 hex = 17 dec = 17 digits
PAN: 1 2345 6789 0123 4567

Alphanumeric field

This field is ASCII encoded. The length is expressed as a number of ASCII characters meaning a number of bytes.

Example:

Field n° 43 – Card Acceptor Name and Address
Attribute: ans-55
Coding: 42 41 58 20 54 65 73 74 20 20 20 20 20 20 20 20 20 20 20 20 20 20 2f 20 20 20 20 20 2f 50 61 72 69 73 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 2f 46 52 20

Length: not specified since fixed length always equal to 55 characters (55 bytes)

Value: "BAX Test / /Paris /FR "

Binary field

This field is encoded in hexa. The length is expressed as a number of bytes.

Example:

Field n° 55 – Chip Related Data
Attribute: LLVAR b…255
Coding: 69 9f 02 06 00 00 00 00 21 00 9f 03 06 00 00 00 00 00 00 9f 1a 02 02 50 95 05 00 00 00 00 00 5f 2a 02 09 78 9a
03 18 01 09 9c 01 00 9f 37 04 0f 01 0e 03 82 02 1a 80 9f 36 02 00 01 9f 10 20 0f a5 01 a0 81 01 00 00 ee af 28 c6 83 81
c2 ed 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9f 26 08 a1 a7 17 06 5f f0 30 a3
Length: 69 hex = 105 dec

4 List of ISO messages supported

4.1 1100 – Detokenization request to the Cloud TSP

The remote Host is using this message for requesting the Cloud TSP to detokenize a message. During the message processing, the Cloud TSP is processing:

• Token domain restriction Controls checks based on the type of token
• Detokenization

Note: This message corresponds to the “Token Authorization Request” message in the ‘EMV Payment Tokenisation Specification Technical Framework v2.0”.

4.2 1110 - Detokenization request response from the Cloud TSP

The Cloud TSP uses this message for communicating the result of the detokenization request message.

It may be either

• Communicating that the detokenization has failed
• Communicating the PAN, PAN related data associated to the token, proprietary data and token-related data
• Depending of the type of payment transaction, check chip data in relation with the token

Note: This message corresponds to the “PAN Authorization Request” message in the ‘EMV Payment Tokenisation Specification Technical Framework v2.0”.

4.3 1120 - Transaction Advice communication to the Cloud TSP (re-

tokenization)

The remote Host is using this message, for communicating the result of the transaction processing to the Cloud TSP and to request the Cloud TSP to retokenize a message.

The result of transaction processing may be either

• ‘transaction approved’,
• ‘transaction declined’
• or transaction previously approved is reversed’.

During the message processing, the Cloud TSP is processing:

• Check related to the PAN value communicated
• Send notification message to the wallet
• Retokenization
• Depending of the type of payment transaction, check chip data in relation with the token

Note: This message corresponds to the “PAN Authorization Response” message in the ‘EMV Payment Tokenisation Specification Technical Framework v2.0”.

4.4 1130 -Transaction Advice communication response from the Cloud TSP (re-tokenization)

The Cloud TSP uses this message for communicating the result of the Transaction Advice communication request message.

It may be either * Failure to retrieve information related to the associated detokenization request transaction in the Transaction History File managed by the TSP * Communicating that the retokenization has failed * Communicating the Token and Token related data associated to the PAN for the current type of transaction and the chip data generated

Note: This message corresponds to the “Token Authorization Response” message in the ‘EMV Payment Tokenisation Specification Technical Framework v2.0”.

5 List of data elements in ISO messages

Table 4 – Fields presence in ISO messages

6 Requests validation by TSP

TSP performs a number of verifications on reception of 1100 and 1120 request messages using information available at TSP level.

6.1 TSP Database

When processing a message request, the TSP is using as a database either

• Token Information stored in the token vault or
• Transaction History File that log information related to transactions previously detokenized in last 18 months.

The retrieval of transaction in the Transaction History File is performed using an index composed of ‘Retrieval reference number + Transaction Date and Time’ corresponding to the concatenation of the field 37 value and field 07 value present in the origin transaction.

The type of “database” used by the TSP is depending on the type of request message.

6.1.1 1100 – Detokenization request to the Cloud TSP

The TSP is capable to process two types of de-tokenization request:

• Type 1 – Detokenization request related to a new transaction: the detokenization has to be performed based on token vault data.
• Type 2 - Detokenization request related to a transaction already performed: the detokenization is based on TSP Transaction History File.

For “type 1” transactions, the Processing Code (field 03) Position 1-2 always equal to “00” (purchase)

The “type 2” transactions are the transactions with Processing Code (field 03) Position 1-2 equals to one of the following values

• 20: Refunds
• 22: Credit reversal
• 52: Credit – return of goods
• 92: Confirmation of a pre-authorization

Note 1: With these 4 types of transaction, the presence of field 55 in the detokenization request message is optional when the transaction is a chip transaction. Note 2: 1100 is optional for these use cases. The 1120 message (Advise) can be sent without 1100 if detokenization, meaning PAN knowledge, is not required.

6.1.2 1120 - Transaction Advice communication to the Cloud TSP (re-tokenization)

The TSP looks up a detokenization request in TSP Transaction History File by using TDT+RRN value as transaction ID. The token tied to the transaction ID is used to look up PAN in token vault. TSP checks PAN in token vault matches PAN in 1120 – Advice Message else an error is returned in Advice response

6.2 Verification on 1100 –Detokenization request to the Cloud TSP

6.2.1 HCE verification flow

Note: this flow applies to any digital wallet that is based on host-card-emulation (HCE) framework and applies software security measures such as single-use-key. Such wallets include Samsung Pay, Google Pay, and proprietary HCE wallets.

6.2.2 Secure Element-based verification flow

(*) A TSP configuration parameter allows the support of two distinct rules related to the management of the field (02, 14, 35) value present in the response message.

• Option 1: The field (02, 14, 35) are using PAN value (result of the detokenization) only when all the TSP checks are passed (TSP action/response code equal to 000). In case of check failure (TSP action/response code different from 000), the TSP echoes the value communicated in the request message.
• Option 2: The field (02, 14, 35) are using PAN value as soon as the detokenization process is successful. Therefore the field (02, 14, 35) are using PAN value even if one of the Token Domain Restriction checks (ei. field 55 validation) fails (TSP action/response code not equal to one of the following values {001, 003, 006}).

This behavior (option 1 or option 2) is configurable per customer (domestic scheme or any closed loop environment).

6.2.3 In-app payment cloud cryptogram verification flow

The in-app payment cloud cryptograms is a functionality provided by Cloud TSP for PSD2 compliance. The overview of the functionality and format of the cryptograms is described in (1).

This flow is enabled by a configuration per customer. For customers in which enabled, the identification of the applicability of the flow is performed by Field 22, Sub-field 1 PAN Entry Mode being ´08´.

(*) A TSP configuration parameter allows the support of two distinct rules related to the management of the field (02, 14, 35) value present in the response message.

• Option 1: The field (02, 14, 35) are using PAN value (result of the detokenization) only when all the TSP checks are passed (TSP action/response code equal to 000). In case of check failure (TSP action/response code different from 000), the TSP echoes the value communicated in the request message.

• Option 2: The field (02, 14, 35) are using PAN value as soon as the detokenization process is successful. Therefore the field (02, 14, 35) are using PAN value even if one of the Token Domain Restriction checks (ei. field 55 validation) fails (TSP action/response code not equal to one of the following values {001, 003, 006}).

This behavior (option 1 or option 2) is configurable per customer (domestic scheme or any closed loop environment)

6.3 Verification on 1120 - Transaction Advice communication to the Cloud TSP (re-tokenization)

7 Message Data Elements Description

This section provides detailed descriptions of all data elements used by Cloud TSP / Remote Host Interface messages.

7.1 Field n° 02 – Primary Account Number

Field n° 03 – Processing Code

Field n° 04 – Transaction Amount

Field n° 07 –Transaction Date and Time

Field n° 14 – Expiration Date

Field n° 18 – Merchant Type

Field n° 19 – Acquiring Institution Country Code

Field n° 22 – POS Data

Field n° 23 – Card Sequence Number

Field n° 35 - Track2 Data

Field n° 39 – Action/Response Code

Field n° 37 - Retrieval reference number

Field n° 42 – Card Acceptor Identification Code

Field n° 43 – Card Acceptor Name and Address

Field n° 48 – Additional data, private

Field n° 49 – Transaction Currency Code

Field n° 55 – Chip Related Data

Field n° 56 – Token Related Data

(*) The list of data that will be included by the TSP in each response message (1110, 1130) are defined for each project during the specification phase.

(1) The device brand and model are dependant of information provided by the wallet. One of both or both fields may be not populated by the wallet. (2) RFU and subject to availability of the suitable information from the wallet.

Field n° 64 – Message Authentication Code

8 Appendix

8.1 Token Assurance Method codification

The values are defined in the document: “Token Authorization Response” message in the ‘EMV Payment Tokenisation Specification Technical Framework v2.0”.

8.2 Storage Type

Attributes of the device that may be used to identify the specific device where a Payment Token is stored.

8.3 Connectivity Requirements

A secure channel must be established between the Cloud TSP and the remote Host (Acquirer server or Bank server) as described below.

8.3.1 VPN

A VPN (IPSEC) coul be used with TLS Server Authentication but not recommended option

8.3.1 TLS Authentication (HTTPS)

The TLS shall be used to get end-to-end encryption. If VPN is used, TLS shall be TLS server authentication otherwise TLS mutual authentication.

The full ISO payload will be exchanged using HTTP Request/Response scheme:

• HTTP Request
• initiated by the remote host
• method POST
• content type: “x-www-form-urlencoded”
• The full full byte array ISO message request is Base64 encoded and present in the Body Request
• HTTP Response
• It contains the synchronous ISO message Response from Cloud TSP.
• The full byte array ISO message response is Base64 encoded in present in the Body Response.
• HTTP Status code
  • 200 if Cloud TSP decodes and parses the ISO message Request. Response will contain the ISO message Response
  • 4xx if Cloud TSP fails to decode and parse ISO message. No ISO message will be present.
  • 5xx connection error. No ISO message will be present.

8.3.3 MAC usage

Usage of MAC is required in all ISO Message (Request and Response). See MAC details

8.4 MAC details

The following principles shall be applied: * All ISO messages are protected using a MAC. * A new MAC key is generated for each ISO Message. * The MAC key is protected using a Encryption key (Key Interchange) * Key Interchange will be exchanged between each party encrypted under a ZMK * The ZMK (Zone Master Key) are exchanged during a key ceremony and imported into HSM.

8.4.1 Key Interchange

KI (Key Interchange) is the encrypted key used to encrypt the ephemeral MAC Key KI shall be exchanged between the parties during the setup phase. KI are exchanged encrypted under ZMK and shall be protected by HSM. KI is identifed by a key index (1 to 255) and allow Key Interchange switchover (key renewal) Key index is present in ISO Message in Field n° 48 – Additional data, private (Identifier "001", the encrypted key index)

8.4.2 MAC key

A MAC key shall be present in each ISO message, encrypted under KI in Field n° 48 – Additional data, private (Identifier "002", the MAC key)

The MAC key is an ephemeral key to be generated by each party and could be reuse in several ISO Messages.

The maximum lifetime recommendation for an ephemeral MAC key is 1 hour.

8.4.3 MAC

MAC shall be computed for each ISO Message. MAC is present in Field n° 64 – Message Authentication Code Input data of the MAC is SHA-256 hash of the full ISO payload encoded to bytes excluding the mac value field (Field 64). Note: SHA-256 hash is used by default. SHA-1 hash can be used under request.

8.4.4 Keys type and algorithms

8.5 Healthcheck interface

A healthcheck mechanism allow testing on a regular basis the peer to peer connectivity. On HTTP request to dedicated URL, HTTP 200 is returned by TSP while the status is up and running.

Both HTTP POST and GET method can be invoked.

URL is formatted as below:

URL: https://<domain name>/gtotx/api/iso/healthCheck

8.6 ISO interface

ISO message are carried over HTTP.

HTTP POST method can be invoked.

URL is formatted as below:

URL: https:// <domain name>/gtotx/api/iso/v10/msg

8.7 ISO8583 request/response examples

Detokenization Request:

----BEGIN ISO MESSAGE-----
MTI : 1100
BitMap : {2, 3, 4, 7, 14, 18, 19, 22, 23, 37, 42, 43, 48, 49, 55, 64}
Field-2 : [603200*******1961]               (PAN - PRIMARY ACCOUNT NUMBER)
Field-3 : [000000]                          (PROCESSING CODE)
Field-4 : [000000002100]                    (AMOUNT, TRANSACTION)
Field-7 : [1017684135]                      (TRANSMISSION DATE AND TIME)
Field-14 : [2809]                           (DATE, EXPIRATION)
Field-18 : [1520]                           (MERCHANTS TYPE)
Field-19 : [250]                            (ACQUIRING INSTITUTION COUNTRY CODE)
Field-22 : [000]                            (POINT OF SERVICE ENTRY MODE)
Field-23 : [000]                            (CARD SEQUENCE NUMBER)
Field-37 : [539053756313]                   (RETRIEVAL REFERENCE NUMBER)
Field-42 : [4992 ]                          (CARD ACCEPTOR IDENTIFICATION CODE)
Field-43 : [BAX Test / /Paris /FR ]         (CARD ACCEPTOR NAME/LOCATION)
Field-48 : [00100210002032A9B4A1883D21FA3E19DBCDF174EB06B000501211AA22BB33CC] (ADITIONAL DATA - PRIVATE)
Field-49 : [978]                            (CURRENCY CODE, TRANSACTION)
Field-55 : [9F02060000000021009F03060000000000009F1A020250950500000000005F2A0209789A031801099C01009F37040F010E0382021A809F360200019F10200FA501A081010000F010A0FA8E8527130F0000000000000000000000000000009F2608F8F415E88CF69EF8] (IC card system related data)
Field-64 : [FA71C3422A48D361]               (MESSAGE AUTHENTICATION CODE FIELD)
----END ISO MESSAGE-----

b64Iso=[EQByBGYACGGCAREGAyABBIYgGWEAAAAAAAAAIQAQF2hBNSgJFSACUAAAAAA1M
zkwNTM3NTYzMTM0OTkyICAgICAgICAgICBCQVggVGVzdCAgICAgICAgICAgICAgLyAgICAgL1Bh
cmlzICAgICAgICAgICAgICAgICAvRlIgQDAwMTAwMjEwMDAyMDMyQTlCNEExODgzRDIxRkEzRT
E5REJDREYxNzRFQjA2QjAwMDUwMTIxMUFBMjJCQjMzQ0MJeGmfAgYAAAAAIQCfAwYAAAAA
AACfGgICUJUFAAAAAABfKgIJeJoDGAEJnAEAnzcEDwEOA4ICGoCfNgIAAZ8QIA+lAaCBAQAA8B
Cg+o6FJxMPAAAAAAAAAAAAAAAAAAAAnyYI+PQV6Iz2nvj6ccNCKkjTYQ==]

Detokenization response:

----BEGIN ISO MESSAGE-----
MTI : 1110
BitMap : {2, 14, 39, 48, 56, 64}
Field-2 : [500050*******0053]               (PAN - PRIMARY ACCOUNT NUMBER)
Field-14 : [2303]                           (DATE, EXPIRATION)
Field-39 : [000]                            (ACTION CODE)
Field-48 : [00100210002032A9B4A1883D21FA3E19DBCDF174EB06B0] (ADITIONAL DATA - PRIVATE)
Field-56 : [0505434C4F5544060753504159484345] Field-64 : [BA0E969272027185] (Token Related Data) (MESSAGE AUTHENTICATION CODE FIELD)
----END ISO MESSAGE-----

b64Iso=[ERBABAAAAgEBAREFAAUAFWAAAFMjAwAALjAwMTAwMjEwMDAyMDMyQTlCNEExODgzRDIxRkEzRTE5REJDREYxNzRFQjA2QjAQBQVDTE9VRAYHU1BBWUhDRboOlpJyAnGF]

Advice request:

----BEGIN ISO MESSAGE-----
MTI : 1120
Field-2 : [500050*******0053]               (PAN - PRIMARY ACCOUNT NUMBER)
Field-3 : [000000]                          (PROCESSING CODE)
Field-4 : [000000000100]                    (AMOUNT, TRANSACTION)
Field-7 : [1017684135]                      (TRANSMISSION DATE AND TIME)
Field-14 : [2303]                           (DATE, EXPIRATION)
Field-18 : [1520]                           (MERCHANTS TYPE)
Field-19 : [250]                            (ACQUIRING INSTITUTION COUNTRY CODE)
Field-22 : [000]                            (POINT OF SERVICE ENTRY MODE)
Field-23 : [001]                            (CARD SEQUENCE NUMBER)
Field-37 : [539053756313]                   (RETRIEVAL REFERENCE NUMBER)
Field-39 : [000]                            (ACTION CODE)
Field-42 : [4992 ]                          (CARD ACCEPTOR IDENTIFICATION CODE)
Field-43 : [BAX Test / /Paris /FR ]         (CARD ACCEPTOR NAME/LOCATION)
Field-48 : [00100210002032A9B4A1883D21FA3E19DBCDF174EB06B000501211AA22BB33CC] (ADITIONAL DATA - PRIVATE)
Field-49 : [978]                            (CURRENCY CODE, TRANSACTION)
Field-64 : [CD643CE4CE197782]               (MESSAGE AUTHENTICATION CODE FIELD)
----END ISO MESSAGE-----

b64Iso=[ESByBGYACmGAAREFAAUAFWAAAFMAAAAAAAAAAQAQF2hBNSMDFSACUAAAAAE1MzkwNTM3NTYzMTMAADQ5OTIgICAgICAgICAgIEJBWCBUZXN0ICAgICAgICAgICAgICAvICAgICAvUGFyaXMgICAgICAgICAgICAgICAgIC9GUiBAMDAxMDAyMTAwMDIwMzJBOUI0QTE4ODNEMjFGQTNFMTlEQkNERjE3NEVCMDZCMDAwNTAxMjExQUEyMkJCMzNDQwl4zWQ85M4Zd4I=]

Advice response:

----BEGIN ISO MESSAGE-----
MTI : 1130
BitMap : {2, 14, 39, 48, 64}
Field-2 : [603200*******1961]               (PAN - PRIMARY ACCOUNT NUMBER)
Field-14 : [2809]                           (DATE, EXPIRATION)
Field-39 : [000]                            (ACTION CODE)
Field-48 : [00100210002032A9B4A1883D21FA3E19DBCDF174EB06B0] (ADITIONAL DATA - PRIVATE)
Field-64 : [42648CBBCC0A7E61]               (MESSAGE AUTHENTICATION CODE FIELD)
----END ISO MESSAGE-----

b64Iso=[ETBABAAAAgEAAREGAyABBIYgGWEoCQAALjAwMTAwMjEwMDAyMDMyQTlCNEExODgzRDIxRkEzRTE5REJDREYxNzRFQjA2QjBCZIy7zAp+YQ==]