The Story of Tatkal Remittance- Eko

On 17^th September 2013, Eko completed six years of its existence as a registered company. While it took over a year to move from a 'pilot' project which started by the end of 2007 to a live one, it was not till late 2009 that Eko discovered a real pain-point its customers faced, and in the process, its (current) primary revenue source. This is the story of Tatkal(Hindi. tatka:l, meaning: instant, right then and there).

Eko went live with the State Bank of India (SBI) through an inaugural transaction at Sumit Gupta's medicine shop in Uttam Nagar on 23rd February 2009.

Invitation to inauguration of the first Eko CSP for SBI

Mugdha's invitation, Barry sir (Retd. Vice Admiral Venkat Bharatan was the CEO of the Section 25 company Eko Aspire Foundation then)

At that point in time, our platform was offline and used to sync up to SBI through transaction dumps and handoff reports sent at the end of day. SBI had been working with ALW (A Little World), a very early participant in the Business Correspondent model promulgated by the central bank. ALW's front end agent device was then an NFC enabled phone and each customer had a card. SBI's Financial Inclusion switch provider Yalamanchili  (YCS) had already created an ISO8583 based transaction interface which was to be used to transfer the card transactions captured by ALW to SBI's Core BankingSystem.

There were a few things that were simply revolutionary about Eko:

1. Eko had a transaction system that simply worked on almost any simple mobile phone; no need for expensive smart cards or NFC enabled devices or add-on devices. Even a Nokia 1100 would do just fine for both the customer and the agent.

2. Eko was based on the pre-paid model. It was the first Business Correspondent who first put funds into the BC account with the bank on day zero and then did customer transactions against and upto the amount pre-funded. Pre-funding was prevalent in the telecom recharge sphere, but Eko had applied it on the BC model. This model de-risked the bank and to an extent even Eko from collection and settlement risk. This is today a norm in the BC world.

3. Eko devised an ingenious strong 2 factor authentication system that used a paper based technique. The system was called OkeKey (we are now using the second generation OkeKey system). This system also acted like an OTP (One Time Password) and ensured that the PIN did not travel in clear text even over an unsecured transport like SMS. Simple, cost-effective, quick and therefore for us, it represented an economically viable method to take secure transactions to every mobile phone that was out there.

We used to interact with a few really visionary people at SBI. First and foremost, Mr. S Mukhopadhyay, who was then GM-Outreach. For innovation to work, someone has to give a chance to the innovator to atleast showcase. Mr. Mukhopadhayay gave us a chance and we are thankful to him for that. Mr. L P Rai was then the DGM Technology for Rural Business and Mr. S S Jain who was the Chief Manager Technology for Rural Business. Without these people, Eko story would definitely not have been what it is today. I am sure my colleagues Mansi and Abhinav who used interact a lot more with them would agree.

Coming back to the interface that SBI had exposed through YCS. It was designed for card based transactions and therefore for proximate transactions (where the participants in the transaction have to be next to each other by design). Eko on the other hand had no such restrictions: as long as two people had a mobile number (or any other unique identifier), they could simply transact. So, to ensure that we could communicate in the same 'card' language, we designed a wrapper that would simply translate Eko's transaction parameters to what was required by the card based system and vice-versa. The aim then was to just ensure that the customer accounts opened at Eko's outlets would be online real-time and we will not have to do any end of day batch jobs for this.

So, in late 2009, the RB-DAU (Rural Banking - Dedicated Accounting Unit) team at SBI comprising of Mr. Shivaji More, Mr. Anil Trimakhe and Mrs. Shubha Shejale, along with the YCS team sitting there sent us the specs for the online transaction integration. This was basically a list of transaction formats describing what fields were required for each and the response formats containing success and failure indicators. Apart from this there was a process designed to migrate customers from our platform called SimpliBank to theirs through batch files- there was no programming interface exposed to us to do this real-time.

One among these transactions was a pair called FTWithdrawal and FTDeposit. It was essentially designed to power ALW's Fund Transfer system where a customer could come to an agent, keep his/ her card, indicate the recipient account holder's account details, provide authentication and the transaction would enable money to be transferred from the account holder's card to any existing account in SBI. This was also termed 'Tatkal'. This tatkal had little or no traction at that time.

Meanwhile, the then DMD, Mr. Diwakar Gupta and Mr. S. Mukhopadhay wondered if the BC model could solve a problem that was unique to the public sector banks, through its use of technology. The problem that the bank faced in its urban branches was that of over-crowding, congestion and therefore the quality and RoI of service. Abhishek, our CEO believed he had an answer there.

Abhishek always maintained that there was a remittance story that we needed to pursue although at that point in time, it was not clear to any of us how exactly this would play out. An earlier assumption was that we would need to open agents and through them customer accounts on both sides of a remittance corridor (like Delhi-Bihar). Then, a person in Delhi will use an agent to load money into his/ her account and then the customer could send money home to a relative in Bihar. The relative in Bihar could visit an Eko agent there and withdraw a required amount. We did pursue this agenda for quite some time. However, we soon realized that setting up both the ends of the remittance pipe was a huge exercise. It would take a significantly large base of agents on the sending and receiving size, a significantly greater effort to educate people on both the sides and consequently significantly deep pockets to be able to pull this off.

The integration took a long time: almost a whole year! Considering that we had to get the leased line in place, do the integration, development, get a number of permissions from a lot of 'departments', UAT, et al. The initial phase only consisted of migrating the customers to the CBS. Harish had helped a lot in getting some of the permissions and the leased line in place.

In June 2010, we sent out a process document that described 'remittance to core' to Mr. L P Rai and his team after a lot of review by Anand and Abhinav at Eko. Mr. Rai liked what he saw and made some suggestions in the process and transaction that have made this product hugely successful and he eventually drove its implementation. We had made a curious twist to the 'Tatkal' tale (ref: 4 paragraphs above) and that led to the birth of 'Tatkal remittance' as we know of today. This product and its clones and variations have today become one of the primary revenue sources for many BCs apart from Eko. What we did was to map the pre-funded account of Eko the BC to a virtual card. Then we did a fund transfer transaction where the FT withdrawal was made from the BC account and the FT deposit leg was made to any existing account on the CBS.

Thanks to the effort put in by our engineering team (which was then a part of another contractor Anduril technologies), we made the first test transaction on our staging platform on 23rd June 2010. After a bit of code hacking (one of those rare moments at Eko where I personally wrote code), we were able to successfully put this on production on 26th June. Matteo dialed the first ever production Tatkal transaction from Eko's Nokia 1200 phone (pic attached) and the transaction amount was Rs. 27 (we deliberately chose an odd number ;).

First tatkal end-to-end

The beauty of the whole system was its sheer simplicity, the ability to make a real-time credit into any of the existing 200 million or so accounts of the State Bank of India (rightfully called the banker to every Indian) and the fact that all that the agent (also called the CSP- Customer Service Point) required was a simple basic mobile phone. Unlike the corridor based remittance that we were earlier trying to pursue, the receiving end of the pipe had already been put in place by the bank and its existing BCs. All we had to do was to serve the source locations of migrants- essentially, urban financial inclusion. In the process, what we also achieved was decongestion of hundreds of bank branches. Customers who had to earlier forfeit their day’s work to travel to the branch, wait for hours in a queue there (most branches work only for a few hours of the day, say 10 AM to 3 PM), now had a great option – an Eko counter at the neighborhood grocery store. Unlike the branch, the store was conveniently open even after their work hours, there was no queue and the customers were at ease in a familiar environment.  The customer handed over cash to the agent along with the recipient’s account number, the agent dialled in the transaction and the money moved in real-time to its destination followed by confirmation messages on their mobile phones. This was Tatkal as we had redefined it.

Tatkal flow

The system ran on a trial basis for a month or so and then it went full steam. The rest is now a part of the history of remittances in India. In the first 10 days, we hit a remittance volume of Rs. 1 crore and by the end of August it touched 5 cr. In the entire year before, we would not have done these volumes! The only marketing we did was to tell a few of our CSPs "Don't tell anyone!". Actually! Today Eko, through its platform SimpliBank has handled over Rs. 6,000 crore (6 billion rupees) in cumulative transaction volumes (all included). We still hold the distinction that almost all of these transactions were done using mobile phones. Not only that; today, there are atleast 5 other companies in India doing more or less the same thing.

While there are a hundred challenges before Eko today and we may only have a few answers as yet, the experience of having gone through the grind, having figured atleast some things out, having built something that real customers really needed, being able to earn a revenue out of it, having done all that on the foundation of technoogy innovation and having seeded an entire industry on its precepts, that has been quite a journey!

ISO 8583. An introduction. Plain and Simple

This post is dedicated to all who have just stepped into the financial transaction processing technology world as we know it and want a primer on one of the most prolific protocols powering this world- the ISO 8583.

Introduction

Almost all of us would have swiped a card or two at an ATM or a PoS terminal (or a Square dongle ;)). At the very least, the card serves as an identity factor. Among other things , the magnetic stripe on each card stores something called the PAN (Primary Account Number). For most credit cards, it is the same as the credit card number printed on the front surface/ plastic.

The act of swiping a card on a card reader essentially involves passing this 'identity' of the card to the electronic sub-system and represents a Card Present type of transaction. Alternatively, one could have typed in this information (card number) on a screen of an online shopping interface but then this would effectively become a Card Not Present transaction.

Anyways, we now have the identity of the card in the electronic form. One of the most popular uses of this information is to let the system know which account to debit. (In case you get confused by 'debit' and 'credit': Debit = Deduct from your card/ account. Credit = Create money in your card/ account. In case you wish to find out more about the Latin origins of the words, start here:Why do accountants use debits and credits instead of simple pluses and minuses?)

Origin

Way back in 1987 (I think), The International Organization for Standardization (ISO) declared a standard called the 8583 to facilitate the flow of transaction information interoperably. I believe Visa and Mastercard had come into existence much before this and some form of interoperability existed even before this standard was declared. The important point is that both Visa and Mastercard had adopted this standard at some point in time. Also, the standard has gone through numerous iterations and various financial institutions have tweaked it to create many flavors/ variants.

What and Why?

So what is ISO 8583? It is one of the many standards describing how to pack certain data fields such that it could reliably be unpacked as well and is mostly relevant for the financial transaction processing world.

So this standard helps the electronic system which reads the card number, the transaction amount and other relevant data fields to pack it all up so that it could be transmitted electronically to a transaction processing system where it could then be unpacked back into individual data components and then processed. It also helps the transaction processing system pack and send the response back to the initiating device where it could again be unpacked and the customer be intimated of the transaction response.

There exist numerous methods for packing and unpacking data. It could be as simple as comma separated fields. Eg: I could choose to send the transaction information as simple comma separated values as:
"1234123412341234,1000,INR,987" (Card Number, Amount, Currency, Merchant ID).

The issue with such a simplistic model of data packing is that it lacks meta information. That is, the message itself does not contain any information on what exactly is being packed in it. Not that it could not have been overcome even with a comma separated version- just that it could get cumbersome. Also, I guess at that point in time, it was important to consider that the packing and unpacking could be coded easily into mainframes, not sure about this one.

Many folks have already begun writing obituaries to the ISO 8583 protocol thanks to the advent of the younger and dynamic (but not leaner) ISO 20022. However, thanks to its proliferation, ISO 8583 will be a difficult one to get rid of soon and hence one way or the other, in this industry you will need to know this veteran.

Principles

The ISO 8583 message is based on the principles that:
a. In a transaction message, you only get to pick any number of fields from a predefined set of fields. So, if you need a field called 'My girlfriend's phone number', sorry, ain't possible.
b. The meta information of which fields are present in the message are also a part of the message payload in a data structure called the 'bitmap'.

Structure

Most implementations contain a few bytes dedicated to a fixed header (eg: ^A^TISO016000010) after which the actual ISO 8583 message starts.

MTI

The Message Type Indicator.
The first 4 bytes describe the message type. Eg:

02 00
which tells that the message is actually a financial transaction request. (The response to this request would also be in ISO 8583 and would carry an MTI: 02 10). Various MTIs exist and can be found on the web.

Bitmap

Now that we know that this is a financial transaction, we would naturally expect a few important fields to be present. But which ones exactly? This is where the bitmap comes into play. It is almost a visual representation of which fields are actually present in this message and which fields are not.

Imagine a switchboard with 64 ON/OFF switches arranged one after the other from left to right. Lets assume that each switch represents each of the 64 main pre-defined fields. (The 1st field is interesting, we will come to that later). For every field that is present in the message, assume that we turn that particular switch ON and for every field that is absent, we ensure that the switch at that position is turned OFF.

For example, assume we had only one field present and if that field was field no. 3, all other switches except the third one from the left would be in OFF position.

If we write 1 for every switch that is ON/ field that is present and 0 for every switch that is OFF/ field that is not present, we get a series of 1s and 0s. This series of 1s and 0s is called the binary bitmap. It is, as I'd mentioned, a linear visual map of which all fields are present in the message payload.


Data Element Map, B64. Binary. 64 bits

Eg:
F2 38 80 01 08 E0 80 0F

11110010  00111000  10000000  00000001  00001000  11100000  10000000  00001111


(all the bit positions that are 1 implies the corresponding fields are present)
Hex  Binary           (Positions that have 1)
F2= 11110010  ->  (1,2,3,4,7)
38= 00111000  ->  (11,12,13)
80= 10000000  ->  (17)
01= 00000001  ->  (32)
08= 00001000  ->  (37)
E0= 11100000  ->  (41,42,43)
80= 10000000  ->  (49)
0F= 00001111  ->  (61,62,63,64)

Bingo, we've just read the map! Therefore the fields that will be present in this message are field numbers: (1,2,3,4,7,11,12,13,17,32,37,41,42,43,49,61,62,63,64)



Note the first bit. Field 1 is a special field which indicates the presence of an extended bitmap. Since this sample message contains 1 on the 1st position, it means that this message contains another bitmap with another 64 bits.

Extended bitmap, b64. Binary 64 bits

80 00 00 00 00 00 00 00
(=hex .extended bitmap field)
(80)10000000 -> (position 64+1=65)

This extended bitmap shows that field number 65 is also present in this message.

Data elements

Immediately after the bitmap, the data elements start serially. From the bitmap we know that fields 2,3,4,7 are present one after the other. All that we need to do is to read them one by one. Each field number has a predefined type in the ISO 8583 definition and has a predefined length. Some fields have variable length in which case the first N bytes provide the length of the field.


Example:

Data Element 2. Length 16. Value : 0000011319353459 = Primary account number
Data Element 3.  Length 6. Value : 011000 =Processing code. 011000 = cash withdrawal
Data Element 4. Length 12. Value : 000000020000 =Amount 200.00
Data Element 7. Length 10. Value : 0804030013 =DateTime DDMMhhmmss
Data Element 11. Length 6. Value : 051028 =Systems Trace number
Data Element 12. Length 6. Value : 083013 =Time, hhmmss
Data Element 13. Length 4. Value : 0804 =Date, MMDD
Data Element 17. Length 4. Value : 0804 =CaptureDate, MMDD
Data Element 32. Length 6. Value : 123456 =Acquiring institution ID code 123456
Data Element 37. Length 12. Value : 192165102801 =Retrievel Ref. No.
...
Data Element 65. Length 50. Value : Customer Withdrawal   =Statement narrative, right pad spaces.


Thats all folks! You've been hereby introduced to the venerable ISO 8583 :). I have only scratched the surface and the intent was a friendly introduction to its structure. There are many more layers involved in actual implementations of the protocol. The following lines could help you learn further.

Additional resources

1.The Wikipedia on ISO8583
2. jPOS - an open source implementation started by Alejandro Revilla and a default choice for many developers
3. (paid) ISO specs: 2003