For consumers who are trying to send a small amount of money from US to a relative in Pakistan, India or Mexico, it probably means queuing at a money-transfer agent, providing documents and other proof of identity and paying a hefty fee, based on the value of the remittance. Similar hurdles and potential fees are observed on the receiving end.

How could these challenges, associated with traditional remittances, be potentially addressed, without need for operating expensive transfer agent networks and without reliance on expensive interbank fund transfers?

Such remittance solution can be cost effectively / easily implemented and offered by traditional banks or specialized money transfer companies by utilizing novel concept of Decoupled Tokenization, which is basis for the implementation of innovative ProxyEMVPay (PEP) Cards

ProxyEMVPay Cards

PEP cards are normal EMV cards, issued as normal Visa, MasterCard or Amex compatible / branded cards, personalized with ISO/IEC 7812 compatible payment token (i.e. ProxyEMVPay card number) and standard set of and EMV cryptographic keys. Basically ProxyEMVPay card is issued ahead of linking it to the REAL underlying payment card credentials. The ProxyEMVPay payment token is therefore ‘decoupled’ from the underlying payment card account and can be in two main states:

1. INACTIVE – when linked to a NULL underlying payment card credentials, inside the PEP Tokenization Service Provider (PEP TSP) server that is in charge of the linking. In this state they can’t be used for payments, i.e. all transactions initiated with INACTIVE tokens are going to be rejected.

1. ACTIVE – when linked to the real and legitimate underlying payment card credentials. In this state ProxyEMVPay cards can be used for payments, as long as TSP server, which is in charge of the linking, confirms and guaranties to the underlying payment card issuer and network that all payment restrictions, attached to the current linking (i.e. max spending allowance, max number of transactions allowed, etc, including payment token EMV cryptogram validation) are satisfied

Set-up

• Remittance recipient obtains (locally) a pre-tokenized, and ‘inactive’ PEP Card, which is compatible with the brand of the payment card behind sender’s bank account (i.e. Underlying Payment Card account).
• Remittance recipient must register PEP Card via PEP Remittance Portal, by providing all required personal data details (as required by the remittance regulations)
• Remittance recipient also provides registered PEP Card Number to the remittance sender
• Remittance sender then ‘activates’ the remittance recipient’s PEP Card
  • Remittance sender uses PEP Remittance Portal (or PEP Remittance Mobile App) and securely links the remittance recipient’s PEP Card Number to remittance sender’s Underlying Payment Card account
    • Sender must prove being a legitimate owner of the underlying payment card and account behind it (usually via 3D Secure process)
  • Remittance sender defines Maximum Remittance Spending Allowance, Maximum Number Of Remittance Transactions for remittance recipient’s PEP Card
  • The established temporary linkage between remittance recipient’s PEP Card Number and remittance sender’s Underlying Payment Card Number (together with Maximum Remittance Spending Allowance and Maximum Number Of Transactions) is securely stored inside the PCI DSS certified PEP TSP server
    • The established linkage represents very efficient and fully secure ‘virtual remittance’ channel
  • Recipient can use the PEP card after it’s been activated up to the currently defined Maximum Remittance Spending Allowance and/or Maximum Number Of Transactions (ATM, POS)
    • Every ATM or POS transaction initiated with remittance recipient’s PEP Card is ‘intercepted’ by the PEP TSP server, which:
      • Verifies PEP Card’s unique per transaction EMV cryptogram value
      • Verifies that current total remittance spend is less than currently defined Maximum Remittance Spending Allowance
      • Verifies that current total number of remittance recipient’s PEP Card transactions is less than the currently defined Maximum Number Of Remittance Transactions
      • PEP Card Number is then de-tokenized into the Underlying Card Number
    • Whenever either currently defined Maximum Remittance Spending Allowance or currently defined Maximum Number Of Remittance Transactions are exceeded the remittance recipient’s PEP Card is ‘de-activated’ (i.e. current ‘virtual remittance’ channel is invalidated)
      • PEP Card Number linked back to NULL Underlying Card Number
      • Maximum Remittance Spending Allowance is set back to 0
      • Maximum Number Of Remittance Transactions is set back to 
    • Remittance sender can establish new ‘virtual remittance’ channel with remittance recipient, at any time, by simply ‘re-activating’ recipient’s PEP Card, i.e. by:
      • Securely linking remittance recipient’s PEP Card Number to its Underlying Payment Card Number
      • Setting new values for Maximum Remittance Spending Allowance and Maximum Number Of Remittance Transactions

BenefitsFor Money Transfer Provider

• Full EMV security, payment credential protection
• Provision of cash on receiving end without using costly agents network
• Ability to enable sender to link his account to PEP cards from multiple recipients (each having its own linkage record and spending restrictions, also in ≠ of countries)

For remittance sender and recipient of funds

• High convenience (fast, secure, ability to withdraw money in multiple parts, no need to carry all cash)
• Cost-effectiveness for both sender and recipient (mainly ATM fees)
• Recipient's ability to spend funds with card at POS
• Recipient's ability to receive funds from multiple senders on same card (at different times)
• Sender's ability to immediately reclaim any 'unused' funds at any time by 'de-activating' the linkage (i.e. 'remittance funds' are not 'locked' in a different account)