digital currency, payment systems bitcoin applepay currentc it’s all in the details digital...
TRANSCRIPT
Digital Currency, Payment Systems
BitcoinApplePayCurrentC
IT’S ALL IN THE DETAILS
DIGITAL CURRENCY
2
• Bitcoin• Currency? Probably not• Asset with Value?
• For tax purposes, yes – like most personal property (proceeds less acquisition cost = gain, etc.)
• For seizure, sale and collection purposes (Silk Road liquidation), yes• For money laundering purposes, probably regulated as a means of value
transfer
• It gets interesting when we start to examine the technical details
• ApplePay• Replaces, augments existing card payment schemes• Has some unusual consequential effects due to technical details
• CurrentC• Proposes to supplant card payment systems, networks, and providers• Merchant-controlled• Has some unusual characteristics in the technical details
Payment Systems in the News (again)
3
• To provide some food for thought with respect to technical differences between modern and leading edge payment systems and prior systems (and each other)
• To provide some context for the analysis of the parties involved in each system, where control points or points of risk exist, where regulatory regimes may apply (and why they may not apply), and to alert you to some of the technological aspects of some of these systems
• DISCLAIMER: the technical bits have been simplified to make the systems capable of being explained and discussed in the brief time we have – shortcuts I’ve made which over-simplify some of the technical aspects are for convenience, and I apologize in advance for that. I have also left out most of the cryptography and communications protocols and events, choosing to summarize to highlight the parties’ roles in the processes and systems described. This is meant to be an overview, not a course in payment system intricacies.
The Purposes of This Discussion
4
• I will describe three systems for comparative purposes:• Bitcoin• ApplePay• CurrentC
• Part of the choice of systems is because they are all in the news these days, and part of it is to contrast and compare their complexity, the parties involved, and some of the aspects related to the analyses of the systems by our legal and regulatory world. Of necessity, this is going to be a “light touch”!
• If there are questions or comments, maybe we can leave them to the end, both because I’m on the phone and can’t see you, and because we have only a short time to cover quite a bit of ground.
• Thank you!
Agenda
5
• Pseudonymous crypto-currency (really a misnomer – should be “crypto-exchange” for value transfer transactions) – is not technically a “currency” (not state-backed)
• Relies upon a distributed computing and distributed storage system which records the entire transaction history of every BTC unit from a “genesis block” to this instant
• Relies upon cryptography to provide authentication of user instructions, and authenticity of the “block-chain” at various points in every transaction
• Relies upon “electronic wallet” applications or “BTC exchange services” provided by third parties (unregulated or rather “lightly regulated” third parties)
• Transactions are essentially irrevocable, may be difficult to trace, and there is no system-provided protection in the event of fraud or hacking – users are on their own
• Public cases of “disappearing BTC”, for instance Mt.Gox exchange losses causing its failure
• Some similarities with cash, but realistically less anonymous than one expects
BITCOIN (BTC)
6
• BTC is a “fiction” which was first generally discussed in a paper published in 2008 and provided in software in 2009
• BTC is meant as a mechanism to transfer value from one account to another by passing information amongst a peer-to-peer network’s users which in essence comprises a complete historical ledger of all BTC created by the system and all transactions between BTC owners and others, with the result that a user can provide evidence supported by the most recent authenticated ledger, called a block-chain, that the user is entitled to a certain number of BTC units.
• The network supports user instructions to transfer BTC units from the user’s account using either “wallet” software or an exchange service on the public internet, which cause the block-chain to be updated – the instructions will typically provide transfers from the user’s account to another user
• Transfer instructions are processed on the peer-to-peer network by computing systems run by third parties called “bitcoin miners”, and the block-chain or historical ledger is updated and verified by these third party “miners” in exchange for new bitcoin from the system, plus transaction fees offered by the transferor as part of the instructions.
BTC – How it Works -1
7
• The maximum number of BTC units permissible by the peer-to-peer network system is 21,000,000 – this is sometimes referred to as the “global BTC supply limit”
• The bitcoin miners’ reward for doing processing work provided by the system automatically (this is where new BTC comes from, until the system stops issuing them at 21,000,000 BTC, estimated to be in about 2140AD), and the miner’s reward is cut in half at every 210,000 blocks processed (the first “halving” occurred in 2013)
• BTC is limited, but may be fractionalized (that is, BTC can be traded in fractional units), however the system limits fractionalization to 10^-8 (0.00000001 BTC)
• The system modifies the degree of difficulty of the miners’ work (in verifying and authenticating the ledger or block-chain) so that generating 2016 new blocks happens every 14 days – this implies that the block-chain updates every about 10 minutes to a new published “state of the ledger”
• The system relies upon cryptography algorithms and on peer-to-peer network software, a variety of wallet and communications with exchange service providers
• Such systems are not invulnerable to fraud or security breach attacks
BTC – How it Works -2
8
• The parties involved in a BTC exchange include (at least):• The inventor of the system• The peer-to-peer network
• Miners• Agglomerations of miners (groups have formed to assemble resources and
share risk)• Network operators (public internet infrastructure)
• End-point user device and software makers • Wallet app providers, distributors• BTC-BTC Exchange operators, software, networks• Sellers of BTC• Buyers of BTC• BTC-Real world exchanges
• For goods or services• For real currency
• Real world threats and regulators
BITCOIN – the Parties
9
• Currency v. Value-repository (asset)• Depository of BTC – is it regulated as a bank (probably not – thank
PayPal, stored value cards, etc)• BTC-BTC Exchange – is it a commodity exchange – unanswered• BTC-BTC transfers (person to person) – caught by money-laundering?
Probably, but enforcement? (maybe against the BTC-BTC exchange systems or large wallet providers?
• BTC-Real world exchanges – purchase of goods and services: sort of normal, but can get strange when BTC exchange rates are volatile, or transactions are incorrect, hard to enforce credits, prove payment (sort of analogous to cash)
• BTC-Real world currency exchanges – not unlike cash; may be analogous to cash deposits and withdrawals using POS/ATM; contract weirdness with ATM system operators; may push risk to exchange operator; contract End User License/Agreement terms push risk to end-user (unlike card issuer and bank user relationships) – no real standards
BITCOIN – some issues 1
10
• Pseudonymity – different from user expectations (not anonymous)• Not immune to fraud, impersonation, hacking, social engineering,
etc. • There are a few easy-to-consider holes in the system:
• Block-race fraud – where a seller of BTC wants to transfer the same BTC twice, it can issue two inconsistent instructions to transfer the same BTC hoping that one is recognized by the purchase and the purchaser’s request to update the Block-chain lags the second instruction to move the same BTC so that the second instruction (typically moving the BTC to an associate of the seller) is accepted as part of the definitive BTC ledger. If that happens, no recourse in the system is available. Private rights would still work as between the seller and the real buyer.
• Wallet sale – the private key access to a BTC-owner’s wallet or BTC account can be sold, rather than selling the BTC itself. This would put the transaction outside of the Block-chain, and make it harder to follow. More like cash in some senses.
• Flaws in the BTC network systems may provide vulnerabilities to manipulate the instructions from users or the formation of new blocks in the chain, which would affect the reliability of the ledger and system
BITCOIN – some issues 2
11
• User acquires wallet software, generates crypto key pair, keeps private key, publishes public key
• User acquires BTC either from an exchange or another wallet, accepts and pays for what is in essence an encrypted proof that a ledger entry recognizing ownership interest in a BTC unit (or fraction) belongs to this user’s wallet (is associated with this user’s crypto key pair).
• User wants to exchange some of the BTC in the account with another user (for some reason that is irrelevant to the exchange, somewhat like the consideration is irrelevant to the dollar bills in a cash transaction – they don’t care what happens but they change hands), and issues instructions which are associated with the wallet, and identify the transaction, the parties (by wallet or account information), the existence of a prior balance of BTC on the ledger to support the transaction, and the user’s instructions about where the BTC are to end up after the transaction
• The instructions are published to the peer-to-peer network
BITCOIN – simplified transaction steps
12
• The miners see the instructions, and process them by authenticating that the BTC in the wallet exist and are available to that wallet for use, effect the transfer, and issue a new version of the ledger with respect to the accounts and BTC involved in the instructions
• The miner which verifies the transaction and builds the first block meeting the system’s requirements for authentication associates the new block with the existing block-chain, and the new block-chain formed is accepted by the system as the authentic current state of the ledger
• The buyer’s wallet may also publish the transaction, which would have been sent to the buyer’s wallet by the seller’s wallet – the miners will have considered this copy of the instruction as well – the buyer’s wallet will authenticate the state of the buyer’s account on the new ledger to confirm that the transaction was recognized
BITCOIN – simplified transaction steps 2
13
• There is no regulated or easily identifiable central clearing system or transaction processor
• Groups of miners have formed to pool resources and effort and share risk
• The peer-to-peer authentication systems rely upon competition between miners, so formation of groups may permit the authentication function to be manipulated by a large group of miners (control of processing power in the peer-to-peer system)
• Specialized hardware has been designed and manufactured specifically configured to be as efficient as possible at “mining” – this is now starting to be regulated by government (a potential chokepoint and a potential point of manipulation of the system)
• This stuff is hard to think about, and the relationships within a peer-to-peer network with many parties is difficult to map, understand, prove, or regulate
• The really interesting point is that the block-chain or ledger is a perpetual, authenticated record of the users’ behaviors and transactions, and that it links on at least some occasions to points in the real world, thus NOT anonymous
BITCOIN – simplified transaction steps 3
14
• ApplePay™ is a more conventional payment system than BTC, but has some similar elements, including the use of a wallet (Passbook App), cryptography (Secure Element, tokens), but it also relies upon existing card issuer and payment processing network infrastructures, and takes advantage of existing POS hardware and internet payment systems.
• Two essential devices are engaged:• POS equipped with NFC • Apple Device with
• Passbook App• Secure Element (hardware element, similar function to the chip on chip-on-card
systems)• Biometric sensor (TouchID or Apple Watch system)
• And a communications network is required to connect the devices to existing payment processing network infrastructure for approval and processing functions
ApplePay ™ - an overview
15
• Apple bears some risk associated with the transactions, takes a 0.15% fee on each POS transaction
• POS transactions are treated as “card present” if done via ApplePay (lower level charge to merchant by payment system)
• Apple had organized the operability of the system with a variety of card issuers before launch
• Within 72 hours, over 1.0 Million user/cards had been “registered” in the ApplePay system (this, presumably, is in addition to cards already registered in Apple’s other payment infrastructures –iTune, AppleID, etc. with which payment methods are associated)
• Should be a relative “no-brainer” adoption at merchants, since the system uses existing standard POS systems equipped with NFC (although tell that to MCX)
• Internet payments are beyond the scope of this discussion (but are possible)
ApplePay ™ - an overview 2
16
• Preconfiguration steps:• User acquires Apple device, installs Passbook App• Passbook App is configured by enrolment of the device, which sends
user’s credit card information to a payment network, which issues a “token” and a “cryptogram” (roughly equivalent to the card number and cryptogram or digital signature included in the “chip” on a “chip on card”). The token is a 16 digit number associated by the payment system with the card account.
• Passbook on the Apple device stores the token and cryptogram in the Secure Element hardware component of the device for that particular card…rinse and repeat (for ea.card)
ApplePay™ - transaction steps
17
• Transaction steps:• POS terminal requests payment at cashier (or equiv)• NFC Passbook App prompts “Pay by ApplePay?” and user authenticates by biometric
(fingerprint – slightly different with Apple Watch device but equivalent security)• Passbook App causes Secure Element to provide Token and Cryptogram generated
by the TouchID system, a unique device code in the Secure Element, and the Token and Cryptogram provided during preconfiguration by the card issuer or payment system, which is a one-time dynamic digital security code that is processed as a “token request” by the payment processing network
• The token and cryptogram are provided to the merchant which passes the transaction request to the payment network for authentication; the network (or if no connection, the POS device with the cryptogram and the unique security code) authenticates the device and App as an accepted “card + PIN” pair, and the POS device passes a token request to the network and then to the card issuer which issues a payment token to the merchant
• The payment is processed as a “card present” transaction in the payment system• The merchant never sees the real credit card, but rather a dynamic code• The PIN is not provided to the merchant, limited information is “harvested” at POS
ApplePay™ - transaction steps 2
18
• Parties Involved• Same as typical credit card payment systems• PLUS
• Apple • Device manufacturer• Secure Element Hardware design and manufacture• Passbook App provider, updater• App Store and Passbook enrolment process and servers
• MINUS• User is not identified by the card number, which is dynamic and changes each
transaction• Loyalty cards and accounts (aside from card-issuer-linked accounts) are not
associated with the transaction• Thoughts:
• Link Apple’s systems to ApplePay enablement, may provide user->user transactions without POS systems, changes information dynamics with merchants
• May help adoption of NFC transactions (NFC can be non-POS device-device
ApplePay
19
• Merchant Customer Exchange (MCX) is a consortium of very large consumer merchants formed to provide and promote a payment system to replace or compete with existing card-payment systems, essentially to reduce transaction fee costs in the members’ sales systems
• MCX has proposed a system called “CurrentC” which does not use NFC, is consistent with existing POS systems (for the most part) using optical scanners, and avoids card systems and existing card payment processors, issuers, and merchant fees.
CurrentC System (as proposed – not launched)
20
• A user acquires a mobile device and a digital wallet App (“CurrentC”)• The user enrols the device and app with a CurrentC server and system,
providing the server and system with the user’s name and credentials, and an existing user bank account at a compatible bank (typically a checking account or debit account) referred to as the “financial account”. This is kept on “secure MCX servers in the cloud”.
• The user is presented by a POS terminal with a payment request• The user chooses payment by CurrentC at the POS, opens the CurrentC App,
opens the user device’s scanner (camera) and scans a QR code on the POS Terminal (OR the POS terminal may use its scanner to scan a QR code on the user’s device). This effects an exchange of information with respect to the transaction (price, merchant, user identity, etc) through the POS system and the MCX cloud servers.
• The MCX cloud servers and the POS system exchange tokens with the bank keeping the financial account to effect funds transfer, and then complete the transaction at the POS, effecting payment and receipt.
• The Wallet may also present the user with a numeric code if a scanner is not available at the POS terminal (which may be entered manually)
Current C – transaction steps
21
• “secure cloud servers” – really?• QR codes instead of NFC – really? On the other hand, backward
compatible with keypads and no radios…• Merchant and MCX harvest a lot of user information• Circumvents card payments systems, like paper cheques used to do• Not available (system not rolled out aside from small alpha test
sites)• On the plus side, this system can also accommodate couponing,
loyalty cards, merchant-specific applications such as personalized coupons or pricing, etc.
• Concerns: the EULA with CurrentC pushes transaction and fraud risk to the user. Device loss is on the user, with no clear way of remote disablement (aside from device-specific or third party)
• Pretty clearly an attempt to pressure card payment providers to reduce fees
CurrentC – some thoughts
