What are BACS, CHAPS and FPS?

They are all payment related systems in use in the UK. So, what's the difference between BACS, CHAPS and FPS?

BACS (Banker's Automated Clearing Service) is the slowest and the oldest of other "automated" payment systems; it's an electronic system to make payments directly from one bank account to another, partially replacing former payment systems such as cash and cheques. The payments go through a central authority, which happens to be be Bacs Payment Schemes Limited. It usually takes 3 days to clear a payment made through BACS.

The Direct Debit system in the UK is based on BACS. Employee wages are also usually sent via BACS by employers.

CHAPS guarantees same-day payments, as long as the instructions are received before 2:30pm on that day. Since this is much faster than BACS, there is a payment processing fee of £25. The network is managed by a company called The Clearing House Automated Payment System.

These days, after the introduction of FSPS (see below), CHAPS usage is mostly limited to high value transactions, such as purchasing a house.

FPS (Faster Payments Systems) was introduced in 2008, promising much faster payment processing as compared to CHAPS; the usual processing time is less than 2-hours, often instantaneous, and there is no processing fee for personal accounts. However, the originator and the beneficiary bank accounts need to be part of the FPS network.

Faster Payments is available 24x7. However, there is an upper limit on the amount that can be transferred in a single transaction via Faster Payments, which happens to be £250,000.

How to parse DE55

DE 55, also called Field 55, in ISO-8583 is Integrated Chip Data; so, it's easy to deduce that the EMV tags of an online transaction should be put in DE 55 when creating the corresponding ISO-8583 financial transaction message. But how?

Well, firstly, one needs to know that EMV tags are BER-TLV encoded in Field 55. Secondly, once you know the encoding itself, it's just a matter of putting all tags together one after another and you get your DE 55---no delimiters and no meta information; it's as simple as that. The only extra stuff that you might need will be the length/ encoding required by the ISO-8583 variant you are implementing. For example, if DE 55 is an LLVAR field, you'll need to add the overall length of the EMV data as LL in DE 55 before putting in all the EMV data.

Below is an example of DE 55 in an ISO-8583 message.

01495F2A0201245F34010182021C008407A0000000031010950580000000009A031102249B0268009C01009F02060000000000009F03060000000000009F0607A00000000310109F0802008C9F0902008C9F100706010A039000009F1A0201249F2608423158936ED6C38F9F2701809F3303E0B0C89F34034103029F3501229F360200019F3704ACAC66E89F5800DF0100DF0200DF0400

Here, 0149 is the LL-part of the LLVAR field, which indicates that the data is 149 bytes (or 298 hex characters), starting from 5F and ending at 00. You can copy this data, excluding the starting 0149, into EMV Lab's TLV Utilities and get this decoding by just a click of the button:

Tag	Value
5F2A	0124
5F34	01
...and so on

What is white label ATM?

It's an "unbranded" ATM---that is, an ATM which is owned by a non-bank entity.

Traditionally, ATM's have been owned by banks. But an ATM is just a machine with some software running inside it. It's possible for a non-banking business entity to own an ATM and make profit from service provided to customers of various banks.

As I said earlier, a white label ATM is one which is owned by a non-banking entity. It seems that the term is more common in India as compared to other countries. The Reserve Bank of India has recently issued a licence to Tata Communications Payment Solutions (TCPS) to operate such machines. 

BER-TLV Encoding of EMV Tags

ISO-8583 messages encode EMV tags using BER-TLV scheme in Field 55 of the message. The formal name of the encoding scheme is ASN.1 Basic Encoding Rule (ISO 8825).

The term TLV stands for Tag Length and Value (sometimes also referred to as Type, Length and Value). For EMV tags, the tag is usually 2-4 bytes in size; the length part is again 2-4 bytes in size,

Valid EMV Tag Names

Some sample EMV tag names are 81, 9F02, 9F26, 4F and 5A. You can find a complete list of tags and their description on EMV Lab's EMV Tags page. BER-TLV encoding rules divide the tag name (sometimes called tag type) into following parts: class (2 bits), primitive/ constructed identifier (1 bit) and tag name (5 bits followed by 0 or more bytes).

Take tag 9F26, for example. In binary, it's equivalent to byte1 = 1001 1111, and byte2 = 0010 0110. The first two bits are 10, which indicate that its class is "Context-Specific". The next bit is 0, which indicates that it's a primitive tag. The next 5 bits of the first byte are all 1, which indicates that the tag name is of the "long form" and we need to look at the next byte as well. All bits in byte 2 form part of the tag name. However, the highest bit of byte 2 (and all following bytes) must be turned on if there are more bytes included in the tag name. In our case, 9F26 is just two bytes; hence, the second byte has it's first bit turned off.

Constructed EMV Tags

The term "constructed" in the context of BER-TLV encoding means that the tag's value is a set of EMV tags itself; i.e., the tag has recursive BER-TLV encoding structure. Let' use Tag 71 as an example.

The hex value of 71 is represented as 0111 0001 in binary. The first two bits are 01 which indicate that it has an "Application" class. The third bit 1 indicates that the tag's value is a set of EMV tags itself. The rest of the bits 10001 indicate the actual tag identifier.

Now, one of the valid values of Tag 71 would be "9F06021234", i.e., the value of Tag 71 is the tag 9F06 along with it's length and content. However, the value "1234" will be incorrect as "1234" is not valid BER-TLV data.

What is ARPC?

ARPC is the cryptogram generated in the response message. Just like ARQC, it ensures that the response originated from the issuer, and that it's not tampered with.

ARPC Generation

ARPC generation is not much different from ARQC generation. The steps for the two cryptograms are similar to each other:

1. Card Key Derivation
2. Session Key Derivation
3. Preparation of Input Data in ARPC Calculation
4. ARPC Calculation (the final encryption/ hashing step)

The major difference in ARPC is that firstly it's generated by the issuer alone, and secondly it usually takes the ISO response code as part of the input data in step 3.

What is ARQC?

Each EMV transaction request is supposed to contain ARQC, which is a cryptogram generated from the transaction data. In the context of EMV, a cryptogram can be thought of as a digital signature on the financial transaction. A valid, verifiable cryptogram tells you two things:

• the financial message originated from the source that it claims to be from
• the contents of the message have not been altered 

There are two cryptograms used in EMV: ARQC (Authorisation Request Cryptogram) and ARPC (Authorisation Response Cryptogram). The first one, ARQC, is generated by the card (after taking some values from the terminal), and hence it's part of a request message. The second one, ARPC, is generated by the issuer and hence it's part of a response message.

Steps for ARQC Generation

There are four basic steps to ARQC generation:

1. Card Key Derivation 
2. Session Key Derivation 
3. Preparation of Input Data in ARQC Calculation
4. Encryption/ Hashing (the final step that gives the ARQC)

Restating the above list, the first step is to derive the card key and then use the card key to derive a session key. In parallel, we need to prepare some data and then encrypt that data with the session key derived in the previous step.

Exact details vary from one chip program to another!

Step 1 and 2: Card and Session Key Derivation

When a card is out in the field, it already contains Issuer Master Key. But to create an ARQC for a particular transaction, two new keys are required: the first key is called Card Key and the second key is called Session Key. Each EMV scheme (such as M/Chip and Visa) has its own algorithm for generation of the card key and/ or the session key. Some of these algorithms are standardized and part of the EMV specification while some others are proprietary with the vendor.

The Card Key is unique to the card and the Session Key is unique to the transaction. It's Session Key which is used for the final encryption in step 4.

Step 3: Data Preparation

In parallel to the key derivation as described above, an important step of ARQC generation is “preparation of input data”, mentioned as point #3 in the list above. Once again, which EMV tags are concatenated to prepare this input data is EMV scheme specific.

Step 4: ARQC Generation 

Finally, once the Session Key and Input Data are ready, the Input Data is encrypted using the Session Key to give the ARQC.

EMV Versions

EMV got standardized in 1995. The first widely used version was EMV 3.0 published in 1996, which is why its popularly known as EMV '96. Some modifications to the standard were done in 1998, giving us EMV 3.1.1.

Another version came out in Dec 2000. Though the formal name was EMV 4.0, it became popularly known as EMV 2000. Finally, another version came out as EMV 4.1 in June 2007, which fortunately didn't get its name altered.

Minor improvements to EMV 4.1 resulted in EMV 4.2 in Jun 2008, and further in EMV 4.3 which was published very recently in Nov 2011.