Message protocol
Every <<glossary:FAST>> message contains an ISO-8583 message in one node. The other nodes (specific to <<glossary:Banking.Live>>) give additional context to a particular transaction.
For a description of the data element (DE) fields in ISO-based messages, we recommend that you refer to the specification relevant to your card scheme.
ISO-8583 standard
ISO-8583 is an international standard for financial transaction card-originated interchange messaging. It is the International Organization for Standardization standard for systems that exchange electronic transactions initiated by cardholders using payment cards.
For more details, you can read more general information on ISO-8583.
Message Type Identifier (MTI / MTID)
Message Type Identifier is a key element which classifies the function of the ISO message. MTI is a 4-digit-long field, and each of the digits has its own meaning:
| Digit position and description | First digit | Second digit | Third digit | Fourth digit |
|---|---|---|---|---|
| ISO 8583 version | Message Class | Message Function | Message Origin | |
| Sample value | 0 | 1 | 0 | 0 |
More details about the columns:
ISO-8583 version
There are a few versions of the ISO 8583 standard:
- ISO-8583:1987
- ISO-8583:1993
- ISO-8583:2003
1987 and 1993 versions are very similar, and version 2003 is very different and was created to be more generic.
| Value | Meaning |
|---|---|
| 0 | ISO 8583: 1987 |
| 1 | ISO 8583: 1993 |
| 2 | ISO 8583: 2003 |
Message class
| Sample values | Message | Meaning |
|---|---|---|
| x1xx | Authorisation message | Determine if funds are available, get approval but do not post to account for reconciliation. |
| x2xx | Financial messages | Determine if funds are available, get approval and post directly to the account. |
| x4xx | Reversal and Chargeback Messages | Reverses the action of a previous authorisation. |
| x5xx | Reconciliation Message | Transmits settlement information message. |
Message function
| Sample values | Meaning |
|---|---|
| xx0x | Request |
| xx1x | Request response |
| xx2x | Advice |
| xx3x | Advice Response |
Message origin
| Sample values | Meaning |
|---|---|
| xxx0 | Acquirer |
| xxx1 | Acquirer Repeat |
| xxx2 | Issuer |
| xxx3 | Issuer Repeat |
| xxx4 | Other |
| xxx5 | Other Repeat |
Commonly used MTIs
Below are the commonly used Message Type Identifiers (MTIs) in <<glossary:Banking.Live>> FAST messages.
| MTID | Message description | Usage |
|---|---|---|
| 0100 | Authorisation Request | Authorisation request from Paymentology to Client |
| 0110 | Authorisation Request Response | Authorisation request response from Client to Paymentology |
| 0130 | Authorisation Advice Response | Authorisation Advice Response from Client To Paymentology |
| 0200 | Financial transaction | Transaction Request from Paymentology to Client |
| 0210 | Financial Transaction Response | Transaction Request response from Client to Paymentology |
| 0400 | Acquirer Reversal Request | Authorisation reversal request from Paymentology to Client |
| 0410 | Reversal Request response | Authorisation reversal response from Client to Paymentology |
| 0120 | Authorisation Advice | Authorisation advisement request from Paymentology to Client |
| 0420 | Reversal advice | Reversal advisement request from Paymentology to Client |
| 0430 | Reversal advice response | Reversal advice response from Client to Paymentology |
| 1240 | Presentment | Submits a completed transaction for settlement; transferring funds from the Paymentology account to the Client's account. |
FAST message structure
Here we define the format and content of all messages that may be exchanged through the <<glossary:Banking.Live>> <<glossary:FAST>> Interface.
The JSON structure sent by <<glossary:Banking.Live>> contains the results of the assessment of the Authorisation/Settlement transaction request, together with the ISO structure set by the relevant card scheme (Visa, Mastercard or Union Pay) and <<glossary:Banking.Live>>'s Rules Engine result.
IMPORTANTNew fields/keys may be added at any point. You must be able to successfully process
<<glossary:FAST>>messages that contain new fields/keys.
In the following sections, we describe the general structure and content of the ISO-8583 messages in the ISO8583: 1993 version.
FAST message nodes
<<glossary:FAST>> messages consist of the following nodes:
| FAST message node | Description | |
|---|---|---|
| 1 | MESSAGE_TYPE | This node contains basic information on the message type and a message description |
| 2 | SUMMARY | This node contains the basic information in the user-friendly narrative for FAST clients to take a financial decision or to use the messages for end-customer consumption |
| 3 | PROCESSOR_VALIDATIONS | This node contains all the non-financial checks performed by the Paymentology system as a processor, in addition to the results of these checks |
| 4 | ISO_MSG | This node will contain the heart of the transactional information as it is received and parsed from the transaction source |
| 5 | RULES | This node is an array of all rules, their descriptive details, along with the relevant actions that have been triggered on the particular transaction |
| 6 | DECISION ENGINE | (If enabled)This node is an array of all decision engine actions along with their descriptive details |
More details about the nodes:
The first node
The fundamental message types and descriptions are as follows:
- 0100 - Authorisation message
- 0120 - Advisement message
- 0400 - Reversal message
- 0420 - Reversal Advisement
The second node
The SUMMARY node holds the main financial data of the message.
| Key | Description |
|---|---|
TID | Unique identifier for transaction thread (Auth, Auth advisement, Reversal, Settlement etc are all linked by same TID). FAST TID |
RID | Unique identifier for each transaction request (Will be same if the same transaction is replayed). FAST RID |
PID | Product Id allocated to the group of cards for any client in the Paymentology platform. |
Client_Id | Client Id allocated to any given client in the Paymentology platform. |
Transaction_Date_Time | Timestamp in the format of "dd-MM-yyyy HH:mm:ss" indicating when this transaction was received by Paymentology irrespective to the network's transmission date and time. |
Network | Abbreviated code to indicate the source (either scheme or switch) of the transaction like MC (Mastercard), VISA, UPI (Union Pay), JTCO (Jetco), CR2, JNET (Jonet), BATM (BAE ATM), MADA etc. |
Spend_Type | Indicates the mode in which the transaction is conducted (e.g. POS, e-commerce) and for what purpose (e.g. purchase, withdrawal etc.) These two components are separated by a hyphen. 1. The first component can be ATM, POS or ECOM. 2. The second component is dependent on the networks DE3_1 (Transaction Type Code) value. You can refer to the Transaction Type Code of the relevant network documentation for further information. |
Spend_Location | Location of the card acceptor where the card information is used for the transaction. |
Transaction_Amount | Decimalized transaction amount in local currency. |
Transaction_Currency | Three-character alphabetic local currency code. |
Billing_Amount | Decimalized transaction amount in billing currency. |
Billing_Currency | Three-character alphabetic billing currency code. |
Card_Use_Type | Indicates the method used for PAN entry in the transaction (PAN entry mode unknown, PAN manual entry, Mag Stripe, Bar code, Optical character reader, Chip, Contactless Chip, Electronic commerce, Card on File, Chip Fallback, Contactless Magstripe, Chip (unreliable CVV)). |
Customer_Validation | Security data validated in paymentology for the transaction (PAN, Online PIN, CVV1, CVV2, CVV3, ARQC, 3DS). Concatenated by '+' if multiple validations. |
Processor_Decision_Code | Suggested response code of the txn to be populated in DE39( but the final decision would be from the client on it). |
Processor_Decision_Desc | Approve or Decline decision description along with hyphen separated reason for declining the txn. |
Processor_Reason_Code | Reason to decline or approve the transaction (in unusual cases). |
Merchant_Category | Merchant numeric code and its description (separated by hyphen). |
Account_Id | Account number associated with the card for the transaction. |
Customer_Ac | Account reference number/code associated with the card that has been agreed with the client. |
Total_Fee_Bill | Total fee applied to the transaction by rule engine in billing currency. |
Add_Ref_RID | Reference RID in order to link the follow-up transactions to their original txn. So the RID of the original txn and Add_Ref_RID in the follow-up txn will be the same. - It has been implemented only for the MADA scheme so far and not for other schemes. |
File_Date | The date at which the settlement file was received. Note: this additional field is present in presentment FAST request only |
Cycle_Info | Settlement cycle information received in the settlement file. Note: This additional field is present in the presentment FAST request only |
Each SUMMARY object includes the following keys:
"SUMMARY": {
"TID": "",
"RID": "",
"PID": "",
"Client_Id": "",
"Transaction_Date_Time": "",
"Network": "",
"Spend_Type": "P",
"Spend_Location": "",
"Transaction_Amount": "",
"Transaction_Currency": "",
"Billing_Amount": "",
"Billing_Currency": "",
"Card_Use_Type": "",
"Customer_Validation": " ",
"Processor_Decision_Code": "",
"Processor_Reason_Code": "",
"Processor_Decision_Desc": "",
"Merchant_Category": "",
"Account_Id": "",
"Customer_Ac": "",
"Total_Fee_Bill": ""
},The third node
The PROCESSOR_VALIDATIONS node holds data about the non-financial checks performed on the message.
| Key | Description |
|---|---|
Pan_Check | Outcome of the PAN check (PASS, FAIL). |
Pin_Check | Outcome of the PIN check (PASS, FAIL, NA, BYPASS). |
Expiry_Check | Outcome of the expiry date check (PASS, FAIL, NA, BYPASS). |
Track_Check | Outcome of the track field check (PASS, FAIL, NA, BYPASS). |
CVV_Type | Number defining CVV type. (0, 1, 2, 3, 4) |
CVV_Check | Outcome of the CVV check (PASS, FAIL, NA, BYPASS). |
ARQC_Check | Outcome of the ARQC check (PASS, FAIL, NA, BYPASS). |
3DS_Check | Outcome of the 3DS check (PASS, FAIL, NA, BYPASS). |
Test_Matrix | Bitmap value indicating all the checks done by paymentology for txn. |
Test_Results | Bitmap value indicating the checks that are satisfied out of all the checks done in the Test_Matrix. |
Rules_Checked | Comma-separated rule ids that have been checked by the rule engine for the transaction. |
Rules_Triggered | Comma-separated rule ids that have been triggered. |
Rules_Decision | Response code from the rule engine which will be DE39 formatted data. |
Each PROCESSOR_VALIDATIONS object includes the following keys:
"PROCESSOR_VALIDATIONS": {
"Pan_Check": "",
"Pin_Check": "",
"Expiry_Check": "",
"Track_Check": "",
"CVV_Type": "",
"CVV_Check": "",
"ARQC_Check": "",
"3DS_Check": "",
"Test_Matrix": "",
"Test_Results": "",
"Rules_Checked": "",
"Rules_Triggered": "",
"Rules_Decision": ""
},The fourth node
The fourth node of a FAST message, ISO_MSG, consists of the original ISO 8583 message received from the relevant scheme (Mastercard/Visa/Union Pay) or switch, in which the card PAN data has been tokenised (to Token ID) for security and <<glossary:PCI-DSS>> compliance
The fifth node
The Rules node provides all the rules listed under a RULES key as an array of the JSON object. Each rule object will reference the rule description and trigger(s) as well as the relevant rule action(s) that are triggered.
Additional controls may be applied at the authorisation level, based on transaction rules and limits that a bank requires, to monitor transactions against client-defined rules, i.e. fraud rules. These rules are set up in the Paymentology rules engine (PayRule) and the Credit engine, and one or more rules can be triggered for a single authorisation message, and each can have multiple actions based on client requirements.
The RULES node provides the structure outlining the rules applied and their respective results.
One or more rules can be triggered for a single authorisation message. Single rules can have multiple actions. All rules will be listed under key Rules as an array of JSON objects.
Under each rule object, there will be the following keys:
"RULES" : [ {
"Rule_Id" : 1,
"Rule_Type" : "Au",
"Rule_Check_Result" : 0,
"Pattern_Result" : false,
"Current_Txn_Amt_Deviation" : -146100.0,
"Aggregate_Deviation" : 0.0,
"Count_Deviation" : 0
]}Rules can have associated Actions, indicating:
- Act
- DE39
- Exit_Code
- Nwk_Status
You can read more on Rules node data fields here.
The sixth node
The Decision Engine element contains only the data of triggered actions.
Each triggered action is represented via:
- id: The unique action ID stored in Paymentology's system
- typeName: The action type
- details: contains action specific data as well as the custom attributes
- attributes: Custom key-value data set by the client during action configuration.
You can read more on Decision Engine node data fields here.
FAST message example
Below is an example of a <<glossary:FAST>> message.
{
"MESSAGE_TYPE": {
"Message_Type": "0100",
"Message_Desc": "Authorisation Request"
},
"SUMMARY": {
"TID": "2453301012345678996",
"RID": "2412345",
"PID": "1111",
"Client_Id": "123456",
"Transaction_Date_Time": "20-09-2023 08:21:41",
"Network": "MC",
"Spend_Type": "POS - Purchase",
"Spend_Location": "W.H.Smith Signature Edinburgh GBR",
"Transaction_Amount": "350",
"Transaction_Currency": "HKD",
"Billing_Amount": "350",
"Billing_Currency": "HKD",
"Card_Use_Type": "Chip",
"Customer_Validation": "ARQC ",
"Processor_Decision_Code": "00",
"Processor_Reason_Code": "000",
"Processor_Decision_Desc": "Approve",
"Merchant_Category": "5499 - Miscellaneous Food Stores-Convenience Stores and Specialty Markets",
"Account_Id": "298123456",
"Customer_Ac": "NA",
"Total_Fee_Bill": "0"
},
"PROCESSOR_VALIDATIONS": {
"Pan_Check": "PASS",
"Pin_Check": "NA",
"Expiry_Check": "PASS",
"Track_Check": "PASS",
"CVV_Type": "4",
"CVV_Check": "BYPASS",
"ARQC_Check": "PASS",
"3DS_Check": "NA",
"Test_Matrix": "2447425042760349112",
"Test_Results": "0",
"Rules_Checked": "12345,12346,12347",
"Rules_Triggered": "12347",
"Rules_Decision": "00"
},
"ISO_MSG": {
"DE2": "736346106",
"DE3_1": "00",
"DE3_2": "00",
"DE3_3": "00",
"DE4": "000000035000",
"DE6": "000000035000",
"DE7": "0920082141",
"DE10": "61000000",
"DE11": "000096",
"DE12": "075120",
"DE13": "0920",
"DE14": "2407",
"DE15": "0612",
"DE16": "0612",
"DE18": "5499",
"DE22": "052",
"DE23": "000",
"DE32": "012345",
"DE35": "736346106D2407***",
"DE37": "085000100002",
"DE38": "10577Z",
"DE41": "12345678",
"DE42": "123456789123456",
"DE43": "W.H.Smith Signature Edinburgh GBR",
"DE48": {
"1": "R",
"38": "Z"
},
"DE49": "344",
"DE51": "344",
"DE55": {
"82": "5800",
"95": "0000000000",
"9F10": "010100A0030000C1",
"9F27": "80",
"9F36": "0028",
"9F34": "1E0300",
"9F33": "E0E8E8"
},
"DE61": "0000000000800826902101234",
"DE63": "MCS0110QI",
"DE95": "000000000000000000000000000000000000001000"
},
"RULES": [
{
"Rule_Id": 12345,
"Rule_Type": "Au",
"Rule_Check_Result": 0,
"Pattern_Result": false,
"Current_Txn_Amt_Deviation": 350,
"Aggregate_Deviation": 0,
"Count_Deviation": 0
},
{
"Rule_Id": 12346,
"Rule_Type": "Au",
"Rule_Check_Result": 0,
"Pattern_Result": false,
"Current_Txn_Amt_Deviation": 0,
"Aggregate_Deviation": 0,
"Count_Deviation": 0,
},
{
"Rule_Id": 12347,
"Rule_Type": "Au",
"Rule_Check_Result": 12,
"Pattern_Result": true,
"Current_Txn_Amt_Deviation": 30,
"Aggregate_Deviation": 0,
"Count_Deviation": 0,
},
]
}Clearing and settlement message payload
Find out more on
<<glossary:FAST>>clearing and settlement payload here.
Updated 28 days ago
