Introduction to ATM Framework

ATM Framework provides a structure to define ISO message fields, provides information for mapping the ISO message fields to Temenos Transact, defines the way the ATM transactions updates Temenos Transact, the ISO response code to be sent  back to the switch, etc. The structure of the ISO message to be sent from the switch and the way ATM transactions updates are done in Temenos Transact can be customised using the framework.

The ATM interface has been widely used across all Temenos Transact installations. ATM framework provides required applications to customise the ISO message according to the requirement of the ATM switch used by the bank.

The ATM interface is developed as a middle layer between the ATM switch and Temenos Transact.  The interface consists of a plug-in for the application server to receive the messages via a dedicated port and translate the ISO messages. The application server sends the ISO message to Temenos Transact, where the ISO message is converted to OFS message format based on the mapping files specified in the interface. After the transaction has been completed in Temenos Transact, the response ISO messages are formatted within the scope of the ATM interface. The response messages are indicated with the appropriate error or ok status depending upon the Temenos Transact applications reply status requested in the framework.

The protocol used for communication between the host and the switch is usually TCP or IP via sockets. ATM interface provides a high performance multi-threaded synchronous socket listener that has custom functionality or intelligence built-in for handling ISO messages with length prefix through TCP or IP.

The application server can be configured for listening ISO messages on any number of ports as required by the load on the site. However, a judicious choice should be made considering the load so that not to leave too many ports listening idly. The switch should try to throw open multiple sockets or connections on the same port(s) when the load increases.

ATM framework supports all standard ATM transactions like cash withdrawal, point of sale, balance enquiry, mini statement, statement request, account transfer, cash deposit and cheque book request.

The ATM interface supports ISO 8583:87 and ISO 8583:93 versions only. Support to different versions will require modification to the ISO message parser routines. The application servers supported by the ATM interface are TC Server, Jboss, Websphere and Weblogic.

• A parameter application to capture the ATM message type to be processed, the type of log to be updated, the location where the log is to be updated, the versions that are to be used to raise ISO request from Temenos Transact, the default terminal Id’s to use for identifying the account for posting transactions, etc.
• A parameter application to capture the ISO response message for success and failure transactions and for failed transactions, the code to be used for each type of error faced.
• A parameter application to capture the charge conditions.
• Additional parameter application to capture extra charges to be posted.
• A parameter application to capture the skeleton of the ISO message to be used.
• A parameter application to capture the ISO message field and its mapping to Temenos Transact fields for each type of ATM transaction and the acquirer of the ATM or POS machine.
• An application to capture the ATM transaction details for information purposes and retrieval during the reversal request.
• Several mapping routines for converting the data in the ISO message to Temenos Transact recognisable value or for mapping it with the required Temenos Transact application.
• Routines for parsing the ISO message and generating the required Temenos Transact transaction and forming the response message in return to the switch, depending on the success or failure of the ATM Transaction and the required response codes mapped in the system
• Routines to generate charges as part of the ATM transaction being processed or raise them as a separate transaction.
• Utility routine to parse the ISO request and response message from Temenos Transact for enquiry purposes.
• Java components for listeners.

• ATM framework is a Gpack offering and is used in many Temenos Transact installations. Adding the functionality as part of the core will enable the delivery through builds and the source code maintenance will be simple.
• Any enhancements to the development will be available for other clients during their upgrade or new installation.

Click here to understand the terms and abbreviations used in this module.

Fast Funds Requests - Debit Cards

Debit cards are part of a payment system issued by financial institutions, such as a bank, to a customer that enables them to access the funds in the customer's bank accounts through ATM, POS and so on. Visa cards are payment cards that use the Visa network, they can be debit, credit, prepaid or gift cards.

With Visa Fast Funds service, the transactions are processed in real-time and funds can be available within 30 minutes of approval, with real-time payment confirmation. This service allows the merchant to generate an authorisation request to credit the card and send it via Visa to the bank. The bank can approve or reject the request subject to the transaction amount limit and posting restrictions on the account.

This functionality enables the bank to handle the Fast Funds authorisation requests received from the merchant using the Visa Fast Fund service and the transactions for debit cards.

The following items have been introduced as part of this functionality:

• The Ff Amount Limit and Ff Suspense Account fields have been added to the ATM.PARAMETER application to define the fast funds' amount limit and suspense account to be debited.
• New configuration records are released to map the authorisation request and response and to define the processing code needed for the fast funds' transactions.

Pre-Authorisation Processing (Insufficient Funds)

Partial Authorisation Service provides an alternative to decline transaction when the card’s available balance is not sufficient to approve a transaction in full. Participating issuers return an authorisation response with an approval for a portion of the original amount requested, enabling the remainder of the transaction amount to be paid by other means using split-tender functionality. These are specific transactions that are done on a point of sale on which the customer initiates the transaction and the real amount to be paid is not known at initiation. The initiation is always done for a maximal amount. This is to prevent that the products or services that are offered to the customer exceed the amount they can pay by the card.

The partial authorisation is allowed for the transactions that are originated from eligible or specific terminals. In case of the insufficient funds, when the available balance is greater than zero but less than the requested amount, the system authorise the request up to the extent of available balance in that account.

The origination of the transaction can be initiated from various terminals like ATM, POS, ECOM, CAT or AFD. This is identified using the functional code present in the ISO message and each terminal has a unique functional code by for which the system can decide whether the partial authorisation is required or not.

The following items have been introduced with this functionality:

• The Partial Auth Data element field has been introduced in the ATM.PARAMETER application to specify the data element,sub-field and position where the partial authorisation codes are present in the ISO Authorisation request.
• The Partial Auth Code field has been introduced in the ATM.PARAMETER application. It represents the value of the data element. Bank can configure the Function codes or Indicators which is used to determine if the message is eligible for partial authorisation.
• The Partial Auth Response Code field has been introduced in the ATM.RES.CODE.TABLE application. This field is used to configure the response message when an authorisation request is partially approved.
• The Partial Auth Flag field has been introduced in the ATM.TRANSACTION application to specify whether an authorisation request is partially authorised.

Transaction History

This functionality allows banks to store the details from the previous messages in the Trans Ref, Mti Code and Transaction Amount fields of the ATM.TRANSACTION application.

Repeat Messages

The repeat messages are sent by the service provider when it doesn't receive the response message from the issuer within the stipulated time. There may be technical reasons like time out, connection lost. etc, due to which a transaction might not get processed, or it would have processed but a response message may not be generated. In these scenarios, the service provider sends a repeat message which will be received by the issuer with the corresponding MTI code ending with 1.

Whenever a repeat message (e.g. x121) is received, it will be checked whether a related message (x120) has already been processed and the corresponding record is captured in the ATM.TRANSACTION application.

• When such a related message (x120) is not received or processed, the repeat x121 message has to be treated and handled in a similar way to the related x120 message.
• On the other hand, if the related message is found to be processed already, then it should not get processed again. Instead, the (x130) corresponding response message has to be generated and sent.

This functionality allows banks to manage the repeat messages of x120/220/420/x100/x200 which is x121/221/421/x101/x201 respectively.

The following diagrams explain the repeat x121, x221 and x421 messages.

Incremental Authorisation

This functionality handles the incremental authorisation.

The incremental authorization allows:

• to increase the amount of the pre-authorization.
• to increase the authorization expiry period (re-authorization).

Example:

Mr.X booked hotel accommodation for 3 days. He has used his card for booking and the rent for 3 days has been locked in his account. Then he wished to extend his stay for 2 more days. In this case, the merchant will be sending the request to increase the existing authorized amount. Likewise, the merchant will send a request to increase the lock period as well.