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 descriptionFirst digitSecond digitThird digitFourth digit
ISO 8583 versionMessage ClassMessage FunctionMessage Origin
Sample value0100

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.

ValueMeaning
0ISO 8583: 1987
1ISO 8583: 1993
2ISO 8583: 2003

Message class

Sample valuesMessageMeaning
x1xxAuthorisation messageDetermine if funds are available, get approval but do not post to account for reconciliation.
x2xxFinancial messagesDetermine if funds are available, get approval and post directly to the account.
x4xxReversal and Chargeback MessagesReverses the action of a previous authorisation.
x5xxReconciliation MessageTransmits settlement information message.

Message function

Sample valuesMeaning
xx0xRequest
xx1xRequest response
xx2xAdvice
xx3xAdvice Response

Message origin

Sample valuesMeaning
xxx0Acquirer
xxx1Acquirer Repeat
xxx2Issuer
xxx3Issuer Repeat
xxx4Other
xxx5Other Repeat

Commonly used MTIs

Below are the commonly used Message Type Identifiers (MTIs) in <<glossary:Banking.Live>> FAST messages.

MTIDMessage descriptionUsage
0100Authorisation RequestAuthorisation request from Paymentology to Client
0110Authorisation Request ResponseAuthorisation request response from Client to Paymentology
0130Authorisation Advice ResponseAuthorisation Advice Response from Client To Paymentology
0200Financial transactionTransaction Request from Paymentology to Client
0210Financial Transaction ResponseTransaction Request response from Client to Paymentology
0400Acquirer Reversal RequestAuthorisation reversal request from Paymentology to Client
0410Reversal Request responseAuthorisation reversal response from Client to Paymentology
0120Authorisation AdviceAuthorisation advisement request from Paymentology to Client
0420Reversal adviceReversal advisement request from Paymentology to Client
0430Reversal advice responseReversal advice response from Client to Paymentology
1240PresentmentSubmits 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.

🗒️

IMPORTANT

New 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 nodeDescription
1MESSAGE_TYPEThis node contains basic information on the message type and a message description
2SUMMARYThis 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
3PROCESSOR_VALIDATIONSThis node contains all the non-financial checks performed by the Paymentology system as a processor, in addition to the results of these checks
4ISO_MSGThis node will contain the heart of the transactional information as it is received and parsed from the transaction source
5RULESThis node is an array of all rules, their descriptive details, along with the relevant actions that have been triggered on the particular transaction
6DECISION 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.

KeyDescription
TIDUnique identifier for transaction thread (Auth, Auth advisement, Reversal, Settlement etc are all linked by same TID). FAST TID
RIDUnique identifier for each transaction request (Will be same if the same transaction is replayed). FAST RID
PIDProduct Id allocated to the group of cards for any client in the Paymentology platform.
Client_IdClient Id allocated to any given client in the Paymentology platform.
Transaction_Date_TimeTimestamp 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.
NetworkAbbreviated 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_TypeIndicates 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_LocationLocation of the card acceptor where the card information is used for the transaction.
Transaction_AmountDecimalized transaction amount in local currency.
Transaction_CurrencyThree-character alphabetic local currency code.
Billing_AmountDecimalized transaction amount in billing currency.
Billing_CurrencyThree-character alphabetic billing currency code.
Card_Use_TypeIndicates 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_ValidationSecurity data validated in paymentology for the transaction (PAN, Online PIN, CVV1, CVV2, CVV3, ARQC, 3DS). Concatenated by '+' if multiple validations.
Processor_Decision_CodeSuggested response code of the txn to be populated in DE39( but the final decision would be from the client on it).
Processor_Decision_DescApprove or Decline decision description along with hyphen separated reason for declining the txn.
Processor_Reason_CodeReason to decline or approve the transaction (in unusual cases).
Merchant_CategoryMerchant numeric code and its description (separated by hyphen).
Account_IdAccount number associated with the card for the transaction.
Customer_AcAccount reference number/code associated with the card that has been agreed with the client.
Total_Fee_BillTotal fee applied to the transaction by rule engine in billing currency.
Add_Ref_RIDReference 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_DateThe date at which the settlement file was received. Note: this additional field is present in presentment FAST request only
Cycle_InfoSettlement 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.

KeyDescription
Pan_CheckOutcome of the PAN check (PASS, FAIL).
Pin_CheckOutcome of the PIN check (PASS, FAIL, NA, BYPASS).
Expiry_CheckOutcome of the expiry date check (PASS, FAIL, NA, BYPASS).
Track_CheckOutcome of the track field check (PASS, FAIL, NA, BYPASS).
CVV_TypeNumber defining CVV type. (0, 1, 2, 3, 4)
CVV_CheckOutcome of the CVV check (PASS, FAIL, NA, BYPASS).
ARQC_CheckOutcome of the ARQC check (PASS, FAIL, NA, BYPASS).
3DS_CheckOutcome of the 3DS check (PASS, FAIL, NA, BYPASS).
Test_MatrixBitmap value indicating all the checks done by paymentology for txn.
Test_ResultsBitmap value indicating the checks that are satisfied out of all the checks done in the Test_Matrix.
Rules_CheckedComma-separated rule ids that have been checked by the rule engine for the transaction.
Rules_TriggeredComma-separated rule ids that have been triggered.
Rules_DecisionResponse 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.