[This article has been reposted to the Galoy blog. It initially appeared on Medium on Dec 9, 2019]

With this article, I want to share my thoughts on the differences between two payment systems: card networks (Visa, Mastercard, etc) and Lightning.

Why is this comparison relevant? Because each of these types of networks is designed for small and high-throughput payments.

By facilitating settlement among banks, Fedwire is the foundation of digital dollars. Bitcoin (the protocol) is the foundation of bitcoin (the currency) and is also what makes transactions between bitcoin holders possible. But because these protocols are restricted to trusted member banks (Fedwire) or don’t scale in throughput (Bitcoin), there is a need for higher-layer protocols that facilitate smaller day to day transactions.

There is a whole category of payment systems that are facilitated by moving numbers in a single database, managed by a single entity, for instance, Paypal, Venmo or even Fedwire. We won’t spend time on those in this blog post.

Some useful definitions:

• Card payment networks include Visa, Mastercard, Amex, Discover, and many other local debit networks.
• Card network policy varies greatly by country. I’m mostly having a US point of view here.
• Issuing banks are the banks that create cards. There is a bank’s name on every card: this is the issuer.
• Acquiring banks are the banks that represent merchants.
• To simplify the narrative, I’ll assume that the merchant is the payee, and that the customer is the payer.
• I’m assuming the usage of non-custodial Lightning wallets.

We’ll dive into the differences between each aspect of the networks.

It’s hard to be exhaustive, given the 10,000+ pages worth of reading to cover every aspect of the card industry. And much of this information is not publicly available nor disclosable. But for the sake of comparison, this article should provide a good overview.

I hope this article will be helpful for anyone learning or working in payments, whether it’s on Lightning or traditional card payments. Leave a comment if you feel this is helpful.

Thanks for the feedback on this post from Alex Bosworth, Bass Bauman, Herve Zenner.

Technical side

Node connection

Every card payment network maintains a list of financial entities they are working with. For example, Visa has about 15,000 members. Visa Inc., the payment network operator, has an agreement with each member of the Visa network.

A large part of the security in this network is related to the fact that a financial entity needs to be a member in order to participate in it, so the security comes from the principle of a walled garden. The way to connect to this network is not publicly disclosed.

Unlike card payment processors, Lightning is an open network.

First, this means the specifications are publicly available.

Second, it means that anyone can join or leave the network at any time.

Some messages are being broadcast to the whole network (eg: there is a new channel between two nodes), some are only transferred between specific nodes (eg: a payment occurring between nodes).

A Lightning node can be connected to as few as one or more than a thousand different nodes. On average, nodes are connected to 11 other nodes. The median is currently 3.

Acquiring or issuing banks are generally connected to Visa, Mastercard, Amex, Discover, and usually a couple of other debits / ATMs networks (NYSE, STAR, etc).

Card networks themselves are connected to every member of their network, eg: 15,000 members. With the permissionless aspect of Lightning, there is more decentralization. The largest node currently has ~1,200 open channels.

A transaction must pass through Visa (or the other associated card network), whereas it may or may not go through one of the large nodes on Lightning.

Graph

Lightning has a concept of payment graphs, which is how nodes connect with each other. Using graph theory terminology, nodes are vertices, and channels are edges.

This graph aspect creates a unique set of challenges for Lightning, as nodes currently need to know about the whole graph before they’re able to initiate a payment. Some solutions such as trampoline payments would help to reduce this burden, especially for mobile phones that are online intermittently.

The notion of a graph is not prevalent in card networks, because each member of the network has only a few static connection points, typically to the mainframe server of the card network. Card networks act as giant routers.

The routing table is relatively easy to define. Each member has a “BIN” which is basically a prefix, represented by the first 4 to 6 digits of a card number. For instance, every card starting with 481582 is a Bank of America Visa debit card. A list (maybe a bit outdated?) can be found here.

A member doesn’t need to know about any other members in the network. It receives every message from the payment network’s central server. For example, an acquiring bank only needs to know about the merchant they are working with and the payment network they are connected to (Visa, Mastercard, etc) but they don’t need to know anything about the card-issuing bank.

Payment authorization and settlement

Protocols rely on the exchange of messages to process a transaction.

For cards, the low-level protocol is ISO8583. The first version was created in 1987, with more recent versions being standardized in 1997 and 2003. Those wire protocols can be seen as low-level version of XML, optimized for bandwidth. The full ISO8583 specifications can be bought from ISO for $232.

Every payment network uses one of the ISO8583 flavors as a starting point and adds their business logic on top of it. Only members of a card network have access to the full specifications. For instance, this would be Base I, Base II, and SMS for Visa.

Since every network implements ISO8583 differently, an ISO8583 message on the Mastercard network differs from an ISO8583 message on the Visa network, and a non-trivial mapping must be implemented by a processor who wants to process messages across both networks.

There are some subtleties around whether a payment comes from a debit card (single message) or a credit card (dual message), but the overall concept is the same. There is a clear distinction between authorization, which happens within seconds of the time a customer initiates a payment, and settlement, done once or a few times per day by batching transactions together. This results in a net settlement principle.

In Lightning, the merchant creates an invoice that the customer receives out of band (with a QR code typically), and then the customer manually approves the invoice by cryptographically signing a message.

If the payment must go through multiple hops between the customer and merchant, it might take a while for the payment to arrive. Although there is a small possibility that the payment can be stuck for a long time if a node unexpectedly goes offline, on average, payments settle in seconds.

On the other hand, with a direct channel between the customer and merchant, a Lightning payment will settle in a subsecond.

But regularly, Lightning payments will be declined, if for instance there is not enough liquidity in some channel along the way.

Payments are declined in the card space for different reasons: if there is not enough money in a bank account, or if the payment is deemed fraudulent, or rarely if the host is offline (this happened to Chime recently and created a lot of frustration).

Since Lightning payments are cleared at the time a payment is sent, this type of payment is in the category of gross settlement.

Message flow

Both card networks and Lightning operate on an electronic level by passing messages across different servers, representing different entities.

For card transactions, the flow is fixed. For an authorization, it basically always looks like this:

[ Image from https://pramodrrao.wordpress.com/2016/05/27/payment-in-brick-and-mortar-world-vs-online-world/ ]

It’s a pull payment in the sense that the merchant’s point of sale is initiating the transaction.

Any merchant that is part of the card network, and has a card holder’s card number, can initiate a transaction to receive money — but this won’t necessarily be approved, cardholder verification may be deemed to be insufficient or a fraud filter may cause the transaction to be declined.

In Lightning, the message flow is not structured as it is for the card system. Anyone can be a merchant, a payer, or an intermediary. It will probably be common to be all of these at the same time!

The unstructured aspect can clearly be seen with this representation of the Lightning network (interactive version):

Lightning is a push system, in the sense that the user always has control of his funds and must approve every transaction. A node can’t pull money from a user’s account.

Cryptography

The use of cryptography for processing transactions really started with the advent of the EMV chip.

The first EMV chip card dates back to 1997, but this technology was introduced in the public in the UK in 2003. In the US, migration from the very insecure magnetic stripe to the much more secure EMV chip continues, slowly. Eg: For some reason, my BitPay card still doesn’t have a chip, which makes it very prone to fraudulent transactions.

The crypto algorithms underlying EMV were chosen multiple decades ago, and could be considered dated due to recent innovations in cryptography, but are still secure for the most part (well, SHA-1 was broken, but that is not enough to compromise card networks

?).

Online authorization uses both TripleDES to create a MAC, called ARPC and ARQC. PIN also uses symmetric encryption with TripleDES. Offline authorization relies on asymmetric cryptography with RSA, SHA-1, and certificates.

Just as ISO8583 defines a framework for financial messaging, EMVCo has defined the base set of functionalities for the EMV chip. This is publicly accessible on the EMVCo website (the cryptography is described in Book 2). Each payment network further specializes the specification, for instance, Visa has V.I.S., or Visa Integrated Circuit Card Specification. This document is only accessible to the members of the Visa network.

The chip is the bearer of the cryptographic keys used for the cryptographic calculations and is considered secure enough to keep the key safe. With millions of dollars worth of equipment, the key might be recovered by an attacker, but because the keys would only apply to the particular card number (keys are unique per card), and because cards themselves don’t hold any fund (unlike crypto), knowing the key would only be helpful to bias authorizations in favor of an approved transaction. This is not worth the effort.

Now…if you do an online transaction (card-not-present, as it’s called in the industry) you’re…back to square one! No strong cryptography to authenticate the transaction.

And it is also the case with cards that are still magnetic.

Most European countries use a form of two-factor authentication (2FA) for online transactions (3D Secure), but this has not been deployed in the US. More and more card transactions are happening online, but they are also the least secure transactions since they don’t rely on strong cryptography. Google Pay and Apple Pay are helping on this as they require a 2FA, and it’s pretty transparent to the users.

Not surprisingly given the open nature of the Lightning network, it makes heavy use of cryptography:

• Payments are currently based on the SHA256 hash function.
• Signing invoices is done with an Elliptic curve (same as for Bitcoin, secp256k1).
• Nodes are identified by public keys, using the same secp256k1.
• Communication between each node is encrypted using ChaCha20, and handshakes are done with the noise protocol.
• Onion routing is reducing the odds of knowing the sender and receiver.

Whereas EMV was designed almost 30 years ago, Lightning relies on recent cryptography that is more secure and can work in an open, but also more hostile, environment.

In contrast to card systems, Lightning doesn’t have a concept of card-present transactions (which make use of cryptography with an EMV), or card-non-present transaction (which don’t). All Lightning transactions rely on strong cryptography.

One comment on the chain of trust. While payment networks have a chain of trust based on contractual agreements, Lightning has a cryptographic chain of trust.

Tech Compliance

With the goal of preventing fraud, the card industry has developed, with the Payment Card Industry (PCI) Security Standard Council, a compliance program called PCI-DSS. The goal is to make sure that every entity on earth that processes card transactions is bound by strict rules that, for instance, make sure that card numbers are not stored in clear text, are accessible only to the people who have a business reason to access those numbers, etc.

The goal of PCI-DSS is to limit fraud in the industry, especially as more and larger hacks happen, disclosing millions of card numbers.

The drawback is the enormous cost of this program, which in aggregate may well be $24.6B by 2022.

Lightning, like Bitcoin, is free of technical mandatory compliance requirements. It doesn’t mean nevertheless that security is not paramount. Lightning are hot wallet so customers have to do some work to safeguard their funds.

Business and financial

Currency

Visa manages 160+ currencies, which may cover all of the government currencies in the world, with the exception of countries sanctioned by the US.

Lightning is often associated with Bitcoin but can operate on pretty much any blockchain protocol that has a hash function, some timing features, and a reliable, predictable settlement layer.

Another important part of the network is currency conversion. Cards today can be used anywhere in the world, to pay for goods and services in pretty much any currency. The currency conversion is done in the back end either by Visa or the card issuer (generating additional revenue), and is transparent to the card user. This is a great innovation that is one less point of friction for frequent travelers such as myself.

Is it different for Lightning? Nope, it’s pretty much the same. Although most of the experimentation today relies on top of the Bitcoin network, there is no technical limitation to sending BTC to settle an LTC invoice. Now the philosophical question is whether it will make as much sense to have different internet currencies for payment, assuming Lightning can scale as much as needed.

An important point is that there is no overlap between the currencies that card networks manage, and the currencies that the Lightning network can work with. Said another way, card networks don’t settle in crypto, and crypto networks can’t “interact” with card networks. The cards that allow you to spend cryptocurrency today does the currency conversion outside of the card network, typically by selling BTC and “loading up” USD.

Will this separation change in the future? Maybe… but does this really make sense?

Financial risk

Let’s dive into the financial aspects of card networks and Lightning, what’s common and what is different.

Liquidity and solvency are key aspects.

Card networks are settling transactions on a net basis. The network is aggregating all the transactions during a period window, for instance, 24 hours (the period is extended for weekends), and then calculating how much each member bank owes or is owed to or from one another.

But to facilitate payments and accounting, card networks act as intermediaries so that the banks that owe money send it to the card network’s bank, and banks that are owed money receive it from the card network’s bank.

Why is that a big deal? Because Mastercard is taking on solvency risk related to all the members of their network.

This flow is clearly described in this paper published by the Fed:

While the majority of funds are transferred within the first few hours after settlement cutoff, MasterCard monitors settlement constantly throughout the day to see who has paid and who hasn’t. If MasterCard sees a position, especially one of $1 million or more, that isn’t settling promptly, that situation is prioritized for action and review.

Let’s dive into the implication of this. As MasterCard takes on counterparty risk related to the members of their network, they want to make sure that those members are well-financed. But as MasterCard operates in 160+ countries, what’s the best way to do it? Partner with banks! Banks are some of the most regulated entities in the world, and relying on the banking system allows Mastercard and other card networks to scale in the number of countries they operate while providing them with the assurance that their members will continue to be solvent.

This is why card payment networks are by nature walled gardens.

As described in this Fed report, settlements are ultimately done through the FedWire network.

There are a lot of other financial risks in card networks, but one that is worth mentioning is the credit risk. This risk is not borne by the card network, but by the issuer.

Lightning is very different in that regard because, for the first time in history, payments can be made instantly, without any counterparty risk, across the world.

So there are no such things as counterparty risk, but instead, Lightning is susceptible to technology risk. A software bug could result in loss of funds as a result of a hack, or a bug could simply make money unspendable. However since Lightning is open source, there is a good reason to believe that, over time, this risk will be drastically reduced.

Liquidity

For Lightning, liquidity is probably the biggest hurdle that must be overcome before it can really take off.

The issue is the following: to be able to pay, a customer needs to have outbound liquidity. To receive a payment, a merchant needs inbound liquidity. Every channel has a defined sum of money in it, split between inbound and outbound liquidity.

At a high level the issue is that:

1. Funds must be locked.
2. If a merchant only receives payments, or a customer only sends payments, then at some point the channel will be “exhausted” and additional payments won’t be possible until channels are rebalanced.

There are a lot of articles that discuss this, so I’ll defer to those for further explanation.

There is no need to lock up funds for members of card networks. Issuing banks are supposed to pay “within the next few hours” when it’s time for settlement. Likewise, acquiring banks (the merchants’ banks) receive their funds in the following hour.

There is a major exception to this. In the US specifically, FinTechs don’t normally apply for a banking license (because it takes many years to obtain one), so instead, they partner with banks. As banks themselves are focused on risk management, they limit their own risk by requiring the FinTech to have a reserve account, which equals a multiple of a FinTech’s daily card transaction volume. This reserve could be seen as similar to the Lightning liquidity lockup.

Fraud

If liquidity is the Achilles heel of Lightning, Fraud is the weakness of the card networks. Not only does it cost a tremendous amount of money to prevent fraud, but fraud itself also costs in the “$100b range” according to The Nilson Report. This is approximately 0.07% of card transaction volume.

The reason this fraud exists is because of the many flows of the card network. Most of this fraud happens either with online transactions, or magnetic stripe transactions, neither of which are secured by the cryptographic components of the EVM and so are easy to counterfeit.

I believe that with Lightning (non-custodial), as long as cryptography is not broken, fraud will be pretty much nonexistent. Is this an unfair advantage?

Chargeback

Chargebacks are related to fraud, but there are some subtleties. Card networks have zero liability policy which is meant to protect card users.

Chargebacks include abusive transactions from unscrupulous cardholders that take advantage of chargebacks, as well as transactions that customers genuinely forget about and then dispute. Since each dispute cost dozens of dollars to resolve, this can be a significant burden, especially for low margin merchants.

This results in increased expense for merchants that must bear the cost of fraud (unless it’s an EMV transaction, in that case, the liability shifts to the issuer); this cost is ultimately passed on to the customer in the form of higher prices for products and services.

Because there is an instant finality in Lightning transactions, there is no such concept of chargebacks. Is that good or bad? I think it’s good because it provides optionality.

Many services do not require chargeback protection. Especially if the payment is individually authorized. Pay for your electricity bill, a movie ticket, a coffee or lunch? Send money to your family? There is no need for an eventual chargeback. The goods and services have already been consumed by the time payments are made, or there is otherwise a trust relationship between the payer and payee.

Now, if you pay for airfare 6 months in the future? Ok, it wouldn’t be the first time a travel company went under, so in this case, being able to dispute the transaction as the service has not been delivered is very valuable. Similarly, this protection gives peace of mind when making payments to online merchants.

But this type of assurance could be dedicated and optional. By unbundling the payment and the insurance for the good or service provided, the cost of the payment can be reduced. This reduction of cost can ultimately be passed on to the customer.

Fees

The fee market is an interesting one. For Lightning, fees are a free market. Any node can set their own fee level per channel, so it’s expected that the fees will become competitive.

Lightning has not yet reached maturity, such that most nodes are operating at a loss today — the fees don’t yet cover the cost of running a secure Lightning node. A rise in fees is expected to happen eventually when a critical mass of payments will shift to Lightning.

For card payments, this is more complex. There are many layers of fees, which vary with regard to the type of merchants and geography. The interchange table from Visa or the fee schedule for merchants banking at Wells Fargo are good indicators of the complexity.

There are primarily 3 fees for merchants:

• Interchange (fees earned by the issuer)
• Network cost
• Acquiring bank cost

Interchange fees and network costs are set by the network operator (except for the debit cards for large banks, these are regulated by the government). Acquiring bank costs are more of a free market.

That said, who is the customer of the network and why is there regularly tension between network operators and merchants?

One could think that the customer of the card networks is the card user…but actually the customer is the card issuer. Why? Because to foster adoption, network operators want to make sure you carry their card. Visa wants you to have a Visa card in your pocket the same way Mastercard wants you to have a Mastercard in your pocket. So how do card networks compete to get more banks issuing cards for their network? Well, they offer more revenue to the issuing banks, and they do this by increasing the interchange! And higher interchange means the merchant has to pay more for the issuer to settle a card transaction.

There is no doubt that card networks have done a tremendous job of facilitating payments, but the fee structure creates a conflict of interest regarding the interchange between issuing banks and merchants.

A simple fee structure, that doesn’t put pressure on merchants, is definitely an opportunity for Lightning.

Privacy

Since card networks are a walled garden, it’s difficult to eavesdrop on transactions easily. Additionally, the only entities that receive the messages are part of the payment and authorization flow. An issuer would only know about the transactions that concern them.

But every intermediary has full details about the transactions (for card-present transactions only the PIN is encrypted). Card networks have to mitigate fraud, so having access to the transaction detail helps them developing algorithms to prevent fraud from happening.

For Lightning, messages are sent encrypted but use onion routing. On paper, this provides great privacy, as intermediaries have only limited information about a particular payment: the previous and next hop and the amount sent inclusive of fees. Unfortunately, it seems the privacy of Lightning is not really as robust as it sounds. Claudia Diaz gave a great presentation on this topic at The Lightning Conference in Berlin.

From an analytics point of view, payments are being tracked closely by the card payment networks, but what would be considered the most important metric, the global payment volume, is something that is just not trackable for Lightning.

Adoption and use cases

While one could argue that the potential use of Lightning is still speculative today given the fact that there are very, very few merchants accepting Lightning today, compared to the 46 million merchant locations accepting 3.3 billion cards issued for the Visa network alone.

The reason Lightning could get traction quickly and exponentially is because it’s open-source and entirely software-based. Every smartphone can become a Point-of-Sale or payment device just by installing a mobile app. This is differentiated from cards that still predominantly rely on some form of hardware. Even Google Pay or Apple Pay payments depend on an NFC receiver, requiring costly upgrades to Point-of-Sale systems.

Some of the unique use cases that Lightning enables:

• Streaming payments

This is extremely relevant in so many areas when consumption is continuous, and would furthermore basically eliminate counterparty risk. Think of paying your electricity in real-time, every couple of seconds as you are using it. Oh, it’s sunny today and you have a surplus of electricity from your solar panel? Payment channels are bidirectional, now you get paid for every watt you provide to your neighbor.

Another obvious use case is pay per use, for instance, an API. Roasbeef, the CTO of Lightning Labs described this use case in detail in his presentation at The Lightning Conference.

• Sub cent / nano payments

Micro donations, paying for an online article, online game…anytime an online sub dollar payment could make sense, the fixed cost of a card transaction prevents these payments from happening.

• Privacy, KYC is optional

Do restaurants need to be aware of the name of every customer having lunch or dinner? Today every person that pays with a card is revealing their identity. Cash is still an option for most places, but in countries like Sweden or China where cash is disappearing rapidly, having the option of a privacy-oriented payment system is valuable. The recent protests in Hong Kong are a great example of why this is important. To avoid revealing their identity, protesters queued to buy transit passes using cash, rather than using digital payment methods.

Closing thoughts

Card networks like Visa are very mature, and from a consumer perspective, they work extremely well.

But there are still inefficiencies and costs underlying the apparent simplicity of the card swipe that are well in the hundreds of billions of dollars a year. Those costs are ultimately paid by the consumer.

Like Bitcoin, Lightning gives back a lot of control back to individuals. But with great power comes great responsibility. Users may lose funds if they don’t properly manage their keys. And a lot of education is needed before billions of people manage their keys confidently.

Yet, the potential benefits of Lightning are tremendous.

First, it enables Bitcoin to be a medium of exchange. The Bitcoin blockchain handles about 5 transactions per second, with a 10 to 60 minute time to finality and a $0.50 to $5 USD cost per transaction.

Second, it enables new payments use cases. While some of the “obvious” ideas have been listed above, many new uses are unimagined. Like with the internet of the eighties and nineties, we still have to discover what Lightning will ultimately enable.

Third, Lightning brings some privacy and can be a key part of freedom of speech and democracy.

To succeed, Lightning still has many challenges ahead, including high liquidity, convenient fiat on and off-ramps, high security, better UX, also some form of tax de minimis exemption in the US. I believe all these will be solved in the coming years.

Probably the biggest question is: how to solve the chicken and egg problem inherent in payment systems — payers and payees need to both use a method of payment — before a network effect and mass adoption kick in?

Card network started on the issuer side, by making sure every person has a card in their pocket. Will Lightning starts the same way, or will merchants favor this first because they have fewer fees associated with it?

‍