Mastercard PayPass

PayPass is a Mastercard Global Contactless payment Brand.

PayPass must be implemented using approved Chip Applicaitons, for example :
  - PayPass - M/Chip 4
  - PayPass - M/Chip Flex
  - M/Chip Advance
  - Mobile Mastercard PayPass - M/Chip 4
PayPass - M/Chip 4
- Extension of the M/Chip 4 Contact-only applicaiton for implementation on a Dual Interface Card.
- Offline Counters shared between contact and the contactless Interfaces.
PayPass - M/Chip Flex
- Supports Different "Contact" Co-Applications
- Dedicated Contactless Offline Limits, not shared between contact and contactless Applications.
M/Chip Advance
- More counters for Risk Management
- Torn Transaction Recovery Mechanism.
- Support for Transit, Loyalty and Voucher Schemes with Data Storage.
Mobile Mastercard PayPass - M/Chip 4
- Application Optimized for Mobile Devices
- Lost and Stolen Protection
- On Device PIN and Acknowledgement
- PIN Control and PIN Management
PayPass Modes of Operation : M/Chip and Magstripe
- PayPass Mag Stripe
   - 100% online
   - Host based credit Control
   - Dynamic CVC3 for counterfeit Protection 
- PayPass M/Chip
   - Configurable Offline/Online
   - Host/Chip based credit Control
   - EMV Application Cryptogram and Offline Authentication for counterfeit Protection  
PayPass Product Rules

Mastercard Types	Mastercard	Maestro	Cirrus
PayPass M/Chip	YES	YES	NO
PayPass MagStripe	YES	NO	NO

Instant Payments: Clearing and Settlement Issues

Instant payments have long been a dream and some companies are putting in significant efforts to make that dream come true.

As consumers, we can already enjoy the convenience of instant payments with Google Wallet that recently enabled instant payments using a phone number.

However, we are still not at a stage when instant payments are a habitual every-day practice. While consumers have extremely high expectations from payments providers, it is actually quite a complex task. One set of important points to consider is the clearing and settlement of instant payments.

At this point, all transactions performed by account holders
 - Need to be cleared (the payment information is validated),
  -And then settled (the funds are transferred between accounts).


Usually,


1) High-value payments between banks are cleared on an individual basis for security matters,
2) While a mass of low-value transactions goes in batches (RTGS) in order to optimize the process.


The entities dedicated to performing those operations are automated clearing houses (ACH), which are either operated by central banks or third-party service providers.


However, the Society for Worldwide Interbank Financial Telecommunication (SWIFT) believes that the clear-cut line between RTGS and ACH is blurring.


ACHs are moving away from single, end-of-day batch processing towards more frequent settlement cycles. As the organization states, as technology becomes cheaper and more accessible, transaction-by-transaction settlement, in central bank money, is becoming more realistic for a larger number of important retail payments. With the possible shift towards RTGS, instant payments have a chance of a fasted introduction as the time between batch clearing is decreasing along with increasing frequency. However, there are important considerations to make in order to speed the pace of introducing instant payments.


Due to the fact that instant payments are supposed to be actually almost instant, clearing and settlement need to be optimized to work 24/7/365. Unfortunately, traditional clearing and settlement are not ready to operate under such conditions. Constant operational availability of the payment infrastructure requires time and resource investment to reduce the potential downtime. As global safety science company UL believes, current clearing and settlement systems are mostly limited to capabilities to continuous clearing and windowed settlement.

As we have mentioned before, an important point to consider is batch settlement versus an individual depending on the value. Traditional systems settle high-value payments individually and batch low-value payments. The system is aimed to diminish the credit and liquidity risks when moving large amounts of funds between banks or governments. Distribution to the batch and individual settlement has a high associated cost and time to process. For instant payments, the system will have to move away from individual approvals and use RTGS for large amounts of transactions.

A single standardization approach (methodology, process, repository) to be used by all financial standards initiatives – ISO 20022 – will lead to the necessity for clearing and settlement mechanisms to support larger amounts of data that are to be treated together with the original transaction. In the case of instant payments, the primary goal of ISO 20022 messaging is seen to be for providing a complete set of data accompanying the typical transaction information.

Risk and fraud opportunities are a strengthening headache when it comes to instant payments. Due to the time taken to clear and settle the transactions, risk and fraud management is in a better position now than it will be with instant payments where no validation will be needed to clear and settle transactions. Security professionals will need to pay extra attention to possible fraud issues with instant payments as the funds will be made available instantly, hence, allowing criminals to perform illegal actions with more freedom and at a higher speed.

In order to mitigate the risks, the European Central Bank suggests that financial institutions implement an infrastructure with appropriate and enforceable measures such as pre-funding, cash guarantee funds and/or securities guarantee funds. In the ideal scenario, such risk mitigation measures should be harmonized across infrastructures to facilitate cross-border interoperability.

Do we need Unified Contactless Kernel at POS?

Contactless/proximity payments are promising technology, bringing speed and convenience to the checkout counter. They are supported by pretty much all payment schemes –
       - Mastercard has PayPass,
       - Visa has payWave,
      -  American Express has ExpressPay,
      -  Discover has ZIP,
      -  JCB has JSpeedy,
      -  Interac has Flash, etc.
This also includes support for NFC-based mobile payments (mainly using so-called ‘NFC card emulation mode’).


At the lowest, so-called ‘transport level,’ all contactless implementations build upon the well-established ISO 14443 NFC standard.


However, at the higher ‘application level,’ all of the payment schemes have different implementations in their attempts to optimize the standard EMV message flow for a faster contactless environment.


On top of the existing contactless implementation differences between payment schemes, within each of the payment scheme’s specific implementations, they offer two different profiles/modes of operation which must be supported – ‘mag stripe emulation’ and ‘optimized-EMV.’

It is a messy scenario for anyone trying to understand and introduce, rollout and support the contactless/NFC technology at the POS.

Here’s what POS vendors, acquirers, and merchants must go through if they want to enable contactless payments:

1. For each payment scheme, they must plan to go through a separate certification process of that scheme’s contactless POS kernel and to have the budget to periodically recertify it. 
2. For each payment scheme, the POS kernel must automatically support and be certified for two separate modes: mag stripe emulation and optimized EMV.

Basically, we currently have five different competing payment scheme contactless implementations, times two different mandatory contactless modes of operation for each payment scheme. That is a total of 10 differently behaving contactless kernels – all basically doing the same simple thing – i.e., executing quick ‘tap payment’ at POS terminal.

Here, we have an opportunity for real innovation – to dramatically simplify the technology stack, reduce the contactless/NFC electronic payment transaction deployment costs, improve the cost of support, and in the end, potentially significantly improve the contactless transaction economics. Isn’t it long overdue for the payment industry to unify behind the single contactless specification (as is already the case with the ‘contact EMV’ standard), put it under EMVco control and follow the same standards? POS vendors, acquirers, and merchants would all welcome such direction.

Blockchain – Bitcoin as a Mainstream Case Study - II

Regular Bitcoin Transactions

I will intentionally ignore ‘coinbase’ transaction messages here because only miners use them and they are irrelevant to the rest of the bitcoin ecosystem participants, although they are the supply source of bitcoins that could be spent. Instead, I will focus mainly on explaining usage rules for ‘regular’ transaction messages, together with the mechanics of their validation by the bitcoin network and the ‘double spend’ protection.


Regular bitcoin transactions are bitcoin’s fundamental building blocks. Since every full node in the bitcoin network has the full current state of the bitcoin distributed ledger, they are all able to validate any new incoming message, which is about to impact the future state of the ledger. To make the process of validation easier and as efficient as possible, the regular bitcoin transaction messages must be formatted according to the agreed-upon standard.

Each bitcoin transaction message consists of (as shown at high-level picture above):

• Header (light blue portion), including ‘bitcoin protocol version’, ‘number of inputs’, ‘number of outputs’ and something called ‘block lock time’ (‘lock time’ basically specifies whether the transaction should be included in the blockchain block immediately after it is validated by the miner node or at some later time)
• One or more input records indexed from 0 up to (n-1) (light green portion)
• One or more output records indexed from 0 up to (m-1) (light orange portion)

Each current transaction input (shown as expanded on the right) contains:

• ‘Hash pointer’ to a previous transaction whose output is referenced by this input
• Index of the referenced output in the previous transaction. That output of the previous transaction always lists the bitcoin address of the initiator of the current transaction as the ‘receiver’ of some amount of bitcoins
• Unlocking script (called ‘scriptSig’) with an indication of its length. It contains the cryptographic proof supplied by the initiator of the current transaction that they are the owner of the key pair {‘sk’, ‘pk’} that can ‘unlock’ the ‘bitcoin spending conditions’, set in the previous transaction output and referenced by this input of the current transaction

Each output (shown as expanded on the right) contains:

• The amount of bitcoins being transferred from the bitcoin address, owned by the current transaction initiator, to some other bitcoin address
• Locking script (called ‘scriptPubKey’) with an indication of its length. Note that it is this Locking Script which specifies the ‘receiver’ bitcoin address together with the ‘bitcoin spending conditions’ for verifying that whoever later wants to ‘spend’ these bitcoins, is the legitimate owner of that ‘receiver’ bitcoin address.

Unspent Transaction Output (UTXO)

The unspent outputs of the previous transactions represent the so-called total Unspent Transaction Output (UTXO) waiting to be spent in future transactions. Bitcoin blockchain doesn’t maintain the individual balances for each of the bitcoin addresses. However, personal bitcoin wallet applications can scan the blockchain database content and the aggregate portion of the total UTXO for the specific bitcoin address (i.e., sums all UTXO outputs where the specific bitcoin address is listed as ‘receiver’ of bitcoins).

Bitcoin Transaction Verification

Who can spend bitcoins from the UTXO accumulated in the outstanding and ‘unclaimed’ outputs of the previous transactions? The answer is: whoever can prove that they are the legitimate owner of the {‘sk’, ‘pk’} key pair behind the bitcoin address, which was listed as the ‘receiver’ of bitcoins in the output of any of those previous transactions.


Let’s use the classic Bob and Alice example to explain how mining nodes verify that Bob is entitled to spend previously sent (i.e., transferred to) bitcoins to him by Alice. I will neglect paying the ‘miner fees’ as irrelevant to keep the description that follows as simple as possible.


Let’s assume that Alice, at some point in the past, owned a total of 1.6 BTCs (bitcoins), which she received in some earlier transaction. To make the diagram as uncluttered as possible, that transaction is not shown on the diagram.


At some point, Alice submitted the bitcoin transaction message (which is shown in the diagram below as Alice’s Transaction Message) in which she splits previously assigned 1.6 BTC into 2 transaction outputs: output #0 sends 0.8 BTC to Bob’s bitcoin address and output #1 sends 0.8 BTC back to her own bitcoin address (considered a simple ‘change’ equivalent). Both outputs of Alice’s transaction contain separate Locking Scripts. The output #0 Locking Script specifies spending conditions for Bob and output #1 Locking Script specifies spending conditions for Alice.

After network miners accept Alice’s transaction and put it in a block, its outputs are automatically considered as part of the new total UTXO. That’s why Alice’s transaction is labeled ‘previous’ – it is already part of the blockchain content.


Now, if Bob wants to ‘spend’ and send those 0.8 BTC (assigned to him by Alice) to Zoe’s bitcoin address, he must prepare his own bitcoin transaction message with 1 input and 1 output (sorry, no change left for Bob in this case).
Bob’s transaction input #0 references output #0 of Alice’s transaction and also contains the ‘Unlocking Script’. The Unlocking Script of Bob’s input #0 contains:

1. A digital signature (produced with Bob’s ‘sk’) of some selected standard transaction data combined from Alice’s and Bob’s transaction messages
2. Bob’s ‘pk’ that can be used to verify that digital signature

How will the verifying node ensure that the ‘Bob’ that submitted the ‘current’ transaction is the ‘real Bob’ who indeed owns the bitcoin address listed in the Locking Script of Alice’s transaction output #0? That’s where bitcoin scripting comes in handy as an automation tool. The verifying mining node simply executes the Unlocking Script from Bob’s transaction input #0, immediately followed by execution of Locking Script from Alice’s transaction output #0. If the final result of combined sequential execution of both scripts returns TRUE, Bob’s proven that he is entitled to spend those bitcoins from Alice’s output #0, otherwise, the transaction is discarded as invalid.


I won’t go into details of how the bitcoin scripting virtual machine manipulates the stack during the execution of the script commands. That has been explained in many articles already. Instead, I will try to describe the main goal of the execution of the script. Basically, the combined sequential execution of Bob’s Unlocking Script and Alice’s Locking Script must prove two things in order for Bob’s bitcoin transaction to be accepted as valid:

1. That Bob’s ‘pk’ when ‘double-hashed’ (first with SHA-256, then with RIPEMD-160) produces a 160-bit output, which exactly matches (bit by bit) the bitcoin address value that was specified inside Alice’s transaction output #0 Locking Script
2. That the supplied digital signature (inside Bob’s transaction input #0) of selected standard transaction data from Alice’s and Bob’s transactions, can be properly verified using the Bob’s supplied ‘pk’ (provided inside Bob’s transaction input #0).

If both steps 1 and 2 result in TRUE condition, then Bob’s right to spend these 0.8 BTC is successfully verified and the transaction can be added to the next blockchain block.

Double Spend Protection

After Bob’s transaction has been fully verified cryptographically, and Bob is proven as the legitimate owner of the ‘spendable’ bitcoins that were assigned to his bitcoin address, the miner must ensure that the referenced bitcoin amount of 0.8 BTC hasn’t already been spent by Bob in a different transaction. In order to protect the bitcoin network from double spending, the verifying mining nodes just need to scan the blockchain content between the blockchain block containing Alice’s transaction and the latest blockchain block. There is no need to go all the way back to the beginning of the blockchain, which makes the whole process of protecting against ‘double spending’ fairly efficient.

Conclusion

So as you could see, with bitcoin transactions, there is no need for any further transaction settlement. It is immediate, fully automated and very secure. The whole process behaves almost as if Alice gave Bob a 1$ bill first and then Bob handed it over to Zoe at a later time. The main difference is that in the case of physical cash, there is no need for proving cryptographically that Bob or Alice owns the cash. Physical possession of cash is the proof, while in the world of bitcoin digital currency, the ‘possession of bitcoins’ needs to be proven and verified cryptographically at the time when it is ‘virtually handed over’ to the next bitcoin address.


Although bitcoin-based payments avoid the need for settlement, they are currently having several orders of magnitude lower transaction processing throughput than the payment card-based systems, due to being completely public and open to everyone’s participation. All that must be managed with fairly complex consensus algorithms involving brute force proof-of-work, puzzle-solving calculations, etc.


But it is certainly an area to watch closely and study very carefully, because the underlying distributed ledger technology and the clever cryptography protection involved has the potential to make even existing EMV payment card payments ‘settlementless’ one day (why not when chips have all the cryptographic power the need?) and also to potentially improve efficiency of the clearing and settlement in any trading of other asset class.

Blockchain – Bitcoin as a Mainstream Case Study - Part I

There are many blockchain implementations in existence today, but bitcoin was the first and still is the most significant and the most successful one.


It has been proven—in extensive real-life exploitation so far—as a very robust and fraud-resistant solution.


Many non-payment use cases have also been implemented on top of the same basic bitcoin blockchain infrastructure, which proves it is also fairly flexible.


For that reason, I believe that the good initial understanding of the bitcoin inner workings can be the perfect basis for understanding every other blockchain implementation and its potential.


Let’s review now—again staying at fairly high level—how the bitcoin payment protocol functions on top of the underlying blockchain database content. Again, I am not going to spend much time diving into all of the details of how bitcoin consensus is executed, managed and reached, but instead will spend most of the time focusing on explaining:

1. What a bitcoin transaction messages structure is
2. How are bitcoin transaction messages validated by the bitcoin network nodes, i.e., how network ensures that available funds are claimed only by the entitled parties that really ‘own’ them

Bitcoin Transactions Primer

Bitcoin transaction messages are the main content of the bitcoin blockchain database. They are commands for the monetary value transfer, usually between a pair of bitcoin ecosystem participants, only identified via their ‘bitcoin address’.


Every participant is required to have the complementary key pair, which they generate using standard tools. The key pair consists of secret key (‘sk’) and public key (‘pk’).


The ‘bitcoin address’ is basically ‘double-hashed’ output (160 bits long) of the participant’s ‘pk’ (first hashed using SHA-256 method then hashed by RIPEMD-160 hashing algorithm).


All bitcoin transaction messages are grouped and stored inside blockchain blocks that are sequentially linked (via their ‘hash pointers’). Every accepted bitcoin transaction message in the bitcoin network is, therefore, available to every node connected to the network. As we have already seen, the immutable and public nature of the content is the basic characteristic of every ‘non-permissioned’ type of blockchain implementation, including bitcoin.

Bitcoin Transaction Message Types

There are two types of the bitcoin transaction messages

1. ‘Coinbase’ transactions – transactions submitted by miners when they successfully ‘mine’ the bitcoin block (and as part of mining operation produce a valid proof-of-work or POW). Miners generate and include exactly 1 coinbase transaction into every bitcoin block to reward themselves for the mining operation
2. ‘Regular’ transactions – when a participant, represented with <Bitcoin Address 1> (including but not limited to miners) wants to transfer ownership of a certain amount of bitcoins (that they can prove they own) to another participant, represented with <Bitcoin Address 2>.

Evolution of ATMs

Automated teller machines have come a long way since Barclays rolled out the world’s first ATM at a branch in north London 50 years ago. Here’s a look at some of the milestone moments and key innovations in ATM technology over the past five decades.

June 27, 1967 - Barclay's Branch made first debut ATMs in North London.
Sep 2, 1969 - Chemical Bank installed first ATM in US, Newyork.
The machine was known as a Docuteller because it was manufactured by the firm Docutel and like most early, it was limited only to customer of the Chemical Bank.
Shared ATMs only introduced after a decade.
1980 - NCR, has introduced first DRIVE ATMs.
1988 - Pittsburgh based equibank was the first bank to offer stamps through ATMs
1999 - Sanfranscisco introduced first Talk ATMs
Video ATMs - ITs Hybrid ATMs between ATMs and a traditional bank experience, where customer might have a face to face conversation with banker. Bank of AMERICA and citizens bank has introduced these ATMs.
2017 - Cardless ATMs has been introduced by Wells Fargo. It allows customer has to withdraw cash only with their smart phones. Customer receive a one time code on their  phone, which they enter into ATM, along with their PIN.
BITCOIN ATMs - These ATMs are NOT part of banking System. But they allow people to convert it into Digital Currency and vice-versa. These machines are introduced in US.

Different Types of ATMs

White Label ATMs

White Label ATMs are those ATMs which set up, owned and operated by non-bank entities. In India, companies which have been incorporated under Companies Act 1956, and after obtaining RBI’s approval. Example : TATAINDICASH


In Netherlands, GSN(Geld Service Netherlands).

Brown Label ATMs

These ATMs are owned and maintained by service provider whereas bank whose brand is used on ATM takes care of cash management and network connectivity.