How to Actually Build to Card Schemes

In the world of payments acquiring there’s probably nothing more alluring than the idea of building directly to the card networks.

But as is the course with everything in payments, nobody knows what the hell they’re talking about.

More often than not the folks who casually throw out the idea of building to the networks are payment ISOs who do so under a pathetically veiled “threat” aimed at their bank and processing partners.

This is completely milk-toothed since no payments company – let alone an ISO – knows how to spell R&D, a major requirement, it turns out, for building software.

ISOs are frustrated because:

1. They are unable to reconcile residuals. This is partly the ISO’s fault and partly the fault of their bank and processing partners, who are incompetent at anything resembling software engineering
2. Service with their processing partner is terrible. If only there was some sign that would indicate how these processors might treat customers and partners…
3. They feel their buy rates are too high, but most ISOs barely push enough volume to cover their costs to the processor
4. ISOs can’t close deals because they don’t have any software to sell, and software is eating payments (this will be upended with AI embeddings, though)

But whatever.

We rolled up our sleeves and undertook substantial research to answer the question: what does it really take to build to the networks?

Turns out it’s harder to pin down than we thought.

In the early 2000’s an interested party would build to the networks by procuring a MIP server from Mastercard and DEX server from Visa. These would be stored in a secure facility after the processor acquired a bank sponsor and spent years building and certifying with the card schemes.

In 2001 the card schemes had these huge binders that contained all the guidelines for writing directly. It was thousands of pages and it would take a few years to consume and certify. But once you built to the networks the work didn’t stop: the networks would issue an update and give you 6 months to re-certify both digitally and physically. It was a treadmill.

Mitch Jacobs, cofounder Plink, former founder OnDeck

Mitch estimated that the cost of building to the networks is $5.3M in today’s dollars, but the ongoing costs were even higher.

I remember after we wrote to the networks they had this encryption update that would be nearly $9M in today’s dollars. And every time a new terminal came out we had to certify that thing. Suffice it to say that you need very large scale to justify the amount of continual investment.

Mitch also acknowledges that procedures might have changed in the past 20-some years since he wrote the integrations, and the networks are “trying” to make it easier for software companies to write to them directly, with explicit divisions now established for direct network connections.

Yet when we reached out to the responsible teams at the networks they couldn’t be bothered to respond.

Cuz, you know, being a duopoly means you don’t actually work. 

This prompted us to talk with people who have done more recent integrations.

We spent a good deal of time with Jason Kafer, a serial payments entrepreneur and co-host of the CentsChat podcast.

Jason tells us it takes 18 months from cradle to grave once you have a sponsoring bank lined up.

“It takes a few weeks or a few years to find a sponsoring bank,” cautions Jason. That’s because the sponsoring bank is signing on the proverbial dotted line on behalf of the processor that wants to write to the networks. This means the bank owns all the risk if the processor screws something up.

Many acquiring banks are skittish about underwriting an unknown processor because the banks themselves don’t know how to appropriately manage the risk of writing to the networks.

The sponsoring bank needs at least $1B in Tier 1 assets per Visa. Tier 1 is in reference to the minimum amount of capital that a bank must hold in its reserves to finance its banking activities as specified in Reg F from the OCC. 

“Technically,” advises Jason, “a processing party could get to a Tier 1 threshold by commingling assets across multiple banks and multiple BIN relationships.” 

Once the bank signs the 18-month timer starts.

But not surprisingly, much of that 18 months is spent waiting for the networks to, you know, get out of bed.

The first step is the audit: the networks audit both the sponsoring bank and the processor.

The purpose of the audit is to ensure that the applying parties are adequately staffed with knowledgeable people to oversee the program. In Visa’s case, the audit is called a GARS (Global Acquirer Risk Standards) audit and in Mastercard’s case it’s called a Franchise audit. 

But Visa doesn’t even do the audit themselves: they outsource it to a third party.

A lot of the 18 months is just waiting on card schemes to do audits. For example, Visa will outsource the GARS audit and it takes time to get in the queue. Mastercard does the audit themselves while Discover and Amex are less stringent on auditing requirements in some areas, but more stringent in other areas because they’re banks and must adhere to banking regulations.

Jason was emphatic that the audit process exists so everyone comes in eyes-wide-open.

If the processor doesn’t architect something right, and it goes haywire, it can bankrupt the bank. 

It’s not a triviality. 

When the audits pass, then you finally get into the technical work of building to the card schemes.

Visa’s documentation is the most complicated. It’s based on the ISO 8583 standard and the documentation is over 2,000 pages in total. It’s separated into two sections: Base I for authorizations (also called VIP internally), and Base II for clearing and settling.

Mastercard calls their integration specifications the Switching Platform for Authorization and Clearing and Settlement and it is likewise over 1,000 pages.

You must also integrate to Amex and Discover, meaning that writing directly to the networks entails maintaining four integrations versus one with a processor.

The card schemes release updates twice per year in April and October, so twice a year you’re making investments to update your platform across – usually – all four networks. And the details matter.

Perhaps the biggest costs are development mistakes. For example, assume Mastercard introduces a new field and you neglect to implement it or implement it properly. Every time a transaction routes through Mastercard you’re going to get hit with fees. If not carefully watched, this can bankrupt your company pretty quickly.

Once you’ve completed the integration, the networks certify your work. On an ongoing basis, you need a dedicated compliance and engineering team to stay on top of the network updates, because if you don’t appropriately make enhancements you could find yourself losing money on each transaction.

A true benefit of writing to the networks is geographic portability: broadly speaking all you need to spin up acquiring in a new country is a sponsoring bank since the majority of the technical lift has been done on your first pass. There are nuances – like no sponsor bank is needed in the EU – but by and large much of the lifting is writing to the networks.

What about the potential savings?

Writing to the networks gets a processor interchange with zero markup. Since it takes a few million dollars to integrate to the networks, you’d need millions of transactions a year to offset the upfront and ongoing costs.

Assume your buy rate with a processor was 4 cents per transaction. You’d need tens of millions of transactions to recoup your investment of network integration. 

You do have annual licensing fees to the schemes in the range of $10,000 annually, so trivial by comparison. 

But building to the networks doesn’t really offer much in itself, frankly.

That’s because for anyone to use the integration it needs additional features. How many additional features depends on the goal of the processor: is it to empower other developers or your own business?

Moov, whose CEO also refused any engagement for the article, has only built a backend tool.

That means Moov has no user experience. Their customers are companies that already have the needed frontend features and want to rip out their backend with a legacy processor.

You want to attract the long tail of the payments industry (like all the ISOs that wanted to build directly)?

Then you need (in no particular order):

• Dispute management
• Interchange qualification
• Statmenting
• Billing
• Onboarding
• Underwriting
• Settlement
• Gateway
• Terminal provisioning
• EMV certifications
• PCI P2PE

It’s a heavy lift. 

And it explains why there are only a handful of processors up and running today. As far as we are aware, Stripe was a decacorn before they bothered writing to the schemes directly, and that’s a software-first company.

Unfortunately for all those ISOs who might think otherwise, building a processor is not as easy as adding fake fees to merchant accounts.