Functional Overview
1. ATM
/ POS Functionality
ATM
Automated Teller Machine, widely used by consumers to perform financial
transactions such as Cash Withdrawals, Cash Deposits, Cheque Book Request, Bill
payments, Mobile Recharges, Funds Transfer between Accounts & non-financial
transactions such as Account Balance Enquiry, Mini Statements Request , Account
Statement Request, Cheque Book Requests etc.,
POS
Point of Sale, this type of transaction is classified into two
1. Card present (Transactions performed over a physical
machine)
2. Card not present (Online
Purchase)
All the mentioned
transaction communicates directly to the core banking application (here it is
T24). ISO8583 is the format which is opted by the financial institutions to
read the financial / non-financial transaction messages that is sent via
switches.
Note:
The transaction types enabled in an ATM / POS machine differs from financial
institutions based on their business necessity.
2. Functionality
in T24
ATM
interface is a middle layer that resides between Switch(ATM) and T24(Host), the
middle layer is connected to the application server with a dedicate port, which
listens for the incoming ISO messages from the interface. The incoming message
is then converted to T24 readable format (OFS - Open Financial Service) to
process the message. Either success / failure the response will be sent back to
the switch in the same manner as it received. The ISO messages are transmitted
from the Switch to T24 via TCP/IP.
Application
Server can be configured for listening ISO messages on required number of ports
(this is decided based on the usage volume of ATM/POS). Application servers
supported by T24 ATM Interface.
TC Server
Jboss
Websphere
Weblogic
3.
How ATM / POS Works?
When
a customer uses an ATM / POS terminal connected to the switch server, the
switch sends a message to T24. Depending upon the message and various
functions, accounting entries are generated in T24 and response message is sent
either with an error or successful details back to the ATM Interface.
Once the interface is
started, the parameters required for the Interface are read from the mapping
tables. Java Listener listens to a port where ATM Switch will be sending the
ISO8583 messages. Once the raw ISO8583 message is read from the port, ATM
Interface converts this raw ISO message into OFS message format and sends it to
T24, for the execution of corresponding transaction. After the transaction has
been completed at T24, the response messages are formatted in ISO8583 format
and sent back to ATM Switch.
The below picture is a generic
demonstration of ATM functional flow in T24.
The below picture is a generic flow chart for ISO message processing in T24
4. How to do ATM testing
To test an ATM interfaces, it is must to know about
ISO messages & their respective data elements in the message, Parameter
setup in T24.
A. ISO
Messages
As mentioned ISO8583 is the format
where the switch exchanges the communication of the transactions to the host
(Core Banking System) made by a card. T24 supports ISO 8583:87 and ISO 8583:93
versions only, where all mentioned financial / non-financial transaction are
supported by both the versions. ISO messages are made of three parts
Message type indicator (MTI)
The first 4 characters after header message is called MTI, indicates of what type of message either Online or Offline which defines how message should flow to the system.
Online
– transaction that happens on real time which hits the host
Offline
– transaction that hits the host after certain interval of time
Example:
0800
>> Request for network sign on
0810
>> Response for network sign on
0200
>> Online request for a financial transaction
0210
>> Online response for a financial transaction
0220
>> Offline request for a financial transaction
0221
>> Financial transactions repeat
0230
>> Offline response for a financial transaction
0420
>> Reversal request
0421
>> Reversal repeat
0430
>> Reversal response
- One or more bitmaps indicating data elements like Transaction Date / Amount / Base Currency / Account Currency / Card data / ATM ID / ATM Location / Country Code
- Reserved fields, Data elements indicating data elements Debit Account Number / Bank Institution ID / Credit Account No / Not used fields
Sample
ISO Message:
ISO0160000700200B23CE4812EB08018000000001400000401200000000053071602121120480292951123470212201002126011826051020514745375576280500007084=20102211629092800000D13657222222000000 IO11129 INFICATT TONTON JB250
634012NETWNETW-003013BNK NETW10100P116340800000009100131441350& 0000200350! BD00328
00000000000005307160000000000000000000634
TT T T00000
00000000000000000000000000000000000000
The
below table indicates the data elements & their values in each position
Position
|
Name
|
Type
|
Mandatory
|
1
|
Bit Map
|
b 64Bit
|
True
|
3
|
Processing code
|
n 6
|
True
|
4
|
Amount, transaction
|
n 12
|
True
|
7
|
Transmission date & time
|
n 10
|
True
|
11
|
Systems trace audit number
|
n 6
|
True
|
12
|
Time, local transaction (hhmmss)
|
n 6
|
True
|
13
|
Date, Local transaction (MMdd)
|
n 4
|
True
|
14
|
Date, Expiration
|
n 4
|
True
|
15
|
Date, Settlement
|
n 4
|
False
|
17
|
Date, capture
|
n 4
|
True
|
18
|
Merchant type
|
n 4
|
True
|
19
|
Acquiring institution country
code
|
n 3
|
True
|
22
|
Point of service entry mode
|
n 3
|
True
|
25
|
Point of service condition code
|
n 2
|
True
|
27
|
Authorizing identification response
length
|
n 1
|
False
|
32
|
Acquiring institution
identification code
|
n ..11
|
True
|
35
|
Track 2 data
|
z ..37
|
True
|
37
|
Retrieval reference number
|
an 12
|
True
|
38
|
Authorization identification
response
|
an 6
|
True
|
39
|
Response code
|
an 2
|
True
|
41
|
Card acceptor terminal
identification
|
ans 16
|
True
|
42
|
Card acceptor identification code
|
ans 15
|
False
|
43
|
Card acceptor name/location
|
ans 40
|
True
|
44
|
Additional response data
|
an ..25
|
True
|
48
|
Additional data – private
|
an …999
|
False
|
49
|
Currency code, transaction
|
a 3
|
True
|
60
|
Reserved national
|
an …999
|
True
|
61
|
Reserved Private
|
ans …999
|
True
|
63
|
Reserved Private
|
ans …999
|
False
|
70
|
Network management Information
code
|
n 3
|
False
|
90
|
Original data elements
|
n 42
|
False
|
95
|
Replacement amounts
|
n 42
|
False
|
100
|
Receiving institution
identification code
|
n ..11
|
True
|
102
|
Account identification 1
|
ans ..28
|
True
|
103
|
Account identification 2
|
ans ..28
|
False
|
121
|
Reserved for private use
|
ans …999
|
False
|
123
|
Reserved for private use
|
ans …999
|
False
|
125
|
Reserved for private use
|
ans …999
|
False
|
126
|
Reserved for private use
|
ans …999
|
True
|
ATM
Parameterization
The
following are the files that are configured in T24 to process the ISO messages
ATM.PARAMETER >> The file stores the
details about user name for the ATM to access T24 application, Bank Institution
ID, ISO version, Processing Code, Mapping filed for unique ID of transaction,
Network ID (VISA/Master), Default ATM /
POS branch & ATM / POS bin numbers.
ATM.BRANCH
>> This
file store the details about the ATM machines belonging to which branch /
location, type of machine (CDM only / ATM & CDM / ATM only), corresponding
ATM GL account numbers.
ATM.BIN.ACCT >> This file stores the
details about receivable and payable accounts for visa/master card transactions
done via ATM only. Id of each record is formed based on the Acquirer bin of
other banks or first 6 digits of PAN No or Network numbers.
ATM.POS.BIN.ACCT
>> This
file is similar to ATM.BIN.ACCT where details about the receivable and payable
accounts for visa/master card transactions done via POS only. Id of each record
is formed based on the Acquirer bin of other banks or first 6 digits of PAN No
or Network numbers.
ATM.CHG.TABLE >> This file stores
charges for all transactions.
ATM.CHG.DETAIL >> This files gets updated
once the details / setup is verified in ATM.CHG.TABLE
ATM.SPLIT.CHG.TABLE
>> This
files stores the values whether the multiple entries to be raised for the transaction
(charges separately). This records defined here should be internally used in ATM.CHG.TABLE
ATM.RES.CODE.TABLE
>> This
file stores the details about what sort of response to be sent to the switch
for the processed transactions.
Example:
Message.1:
Invalid Account Response Code.1: 76, means the host will respond with “76”, as
response code for the failure transactions due to invalid accounts.
INTRF.MAPPING
>> this
files stores the details about the values that to be consider for processing the
transaction. Mapping records for each transaction, which indicates what
application, version to be used to raise accounting entries.
5. Challenges faced
- Connection establishment between the SWITCH and application server
- T24 fails to read the messages from the application server queue, configuration changes to recognize the incoming messages (Ex: Messages available in MQ, but T24 fails to process it)
- Transaction processing fails due connection timeout between the SWITCH & application server (Timeout settings that need to be handled at SWITCH, application server & the host T24)
- Parameter Setup missing in T24
- Transaction processing per minute, if throughput of transaction is more in number, TOT of each transactions increases (performance measures)
- Monitoring the listener port & the sender port configurations frequently
- Monitoring the queue depth frequently & clearing the messages from the queue if by taking backup of the data in the queue
- Revisit the above mentioned parameter setup related to ATM in T24
- Get the details from the bank about their ATM usage transactions per day & accordingly configuration changes needs to be setup at application server level (performance testing)
- Add ATM matrix for better coverage
- Sample test cases that to be covered
- Consideration of locked (blocked) amounts in the account
- Example:
- Wrong balance is shown to the customers when balance enquiry transaction is performed
- Raising wrong account entries in case of insufficient balances
- Consideration of other branch customer accounts and type of account for financial transactions
- Example:
- Customer accounts are differentiated based on which branch they belong, so frequent failure happens due to other branch accounts (apart from Main Brach)
- Financial transaction failing for Savings account but working for current account
- Incorrect mapping of response code which is sent back to the SWITCH
- Example:
- Consider that the SWITCH expects “00” response code for any successful transaction, but instead some other code is sent, in this case the SWITCH considers the transaction as failure but the customer account would have been debited
- Off us transaction failures
- Example:
- Cash withdrawal from other financial institutions that does not use T24 ATM interfaces
- Cash withdrawal using other financial institutions card / credit card in SWITCH that is integrated with T24 ATM Interface
- View Mini statement
- Example:
- Failure happens due to length of the transaction description of an account
- When no transactions are available in an account
- Transactional charges / fees not debited from the account
- Example:
- Transaction fee which supposed to be collected for the financial transaction is not debited from the customer account, due to incorrect charge setup and also the logic of handling debit entries for fee transactional charges
- Void financial transactions
- Example:
- Transactions that supposed to be reversed are not exactly reversed in the account, this mostly happens in case of transaction time out.
Note:
Without a physical ATM / Simulator, T24 ATM Interface can be tested by placing the incoming ISO message in the application server or post the ISO message via telnet.
Without a physical ATM / Simulator, T24 ATM Interface can be tested by placing the incoming ISO message in the application server or post the ISO message via telnet.
Performance
of the T24 ATM interface can be tested by sending ISO messages as a bunch to
the application server queue.