How To Accurately Calculate Interchange & Scheme Fees

Understanding Maturity and How To Implement Logic in the Initial Awareness Stage

In this newsletter, I will share the Interchange & Scheme Fee Capability Maturity Model in more depth, as well as take you through the first stages of Initial Awareness and what that development looks like.

This model, along with understanding HOW to actually build interchange and scheme fee logic, has been a red line through my 20 years in payments.

From ensuring that we were profitable when I was an Issuer at the beginning of my career to helping two of the largest Acquirers in the world level up their predictive capabilities and implement systems and logic to ensure 100% passthrough of interchange plus fees.

Let’s Dive In.

The Payments Industry Thrives On Complexity

The payments industry, despite its outward simplicity, thrives on complexity. At the heart of this complexity are interchange and scheme fees, the often opaque charges that dictate how much merchants pay to accept card payments. This intricacy serves the interests of schemes and acquirers, who benefit from PSPs' lack of understanding. By keeping interchange and scheme fees convoluted, they maintain control and profitability, often at the expense of PSPs and merchants. As someone who has navigated these murky waters with companies like Adyen, Checkout.com, and others, I've seen firsthand the importance of demystifying these fees to build a successful payments business.

Introduction of the Interchange & Scheme Fee Capability Maturity Model

To help Payment Service Providers (PSPs) understand and navigate this complexity, I've developed the Interchange & Scheme Fee Capability Maturity Model (ISFCMM).

This model outlines the stages of maturity for PSPs in handling interchange and scheme fees, from initial awareness to advanced data-driven processing.

1. Initial Awareness Stage: PSPs and ISOs operate with minimal understanding of interchange rates and scheme fees, relying heavily on third-party providers. The focus here is on basic reselling with a simple buy-low, sell-high model.

2. Basic Implementation Stage: PSPs with growing volumes begin to engage more with interchange plus models. Blended pricing is still common, but there's an increasing need to understand the impact of different interchange rates and scheme fees on margins.

3. Rule-Based Processing Stage: PSPs achieve greater volume and obtain their own BINs and ICAs. Accurate processing of interchange rates and scheme fees becomes critical to avoid losses, necessitating complex rule-based systems.

4. Advanced Data-Driven Processing Stage: Few acquirers reach this stage, where predictive calculators based on authorization data forecast final fee calculations. This level of sophistication allows for real-time insights and superior cost management.

When Should a Payment Service Provider Advance to the Next Level?

Deciding when to advance through the ISFCMM stages depends on several factors, including annual processing volume, merchant focus, and the complexity of fee structures.

• Initial Awareness to Basic Implementation: PSPs should consider advancing when their annual processing volume approaches €10 million, indicating the need for more accurate fee calculations and better control over margins.

• Basic Implementation to Rule-Based Processing: Transition to this stage when the annual processing volume approaches €100 million and the merchant base starts, including medium-sized businesses demanding more sophisticated pricing and transparency.

• Rule-Based Processing to Advanced Data-Driven Processing: Move to this stage when the annual processing volume approaches €1 billion, and there is a need for predictive fee calculations to manage higher transaction volumes effectively.

What Are the Benefits and Downsides of Advancing to the Next Level?

Each stage of the ISFCMM offers unique benefits and downsides:

• Initial Awareness Stage:

  • Benefits: Low complexity, cost-effective, focus on sales.

  • Downsides: Limited understanding, reliance on third parties, missed optimization opportunities, and compliance risks.

• Basic Implementation Stage:

  • Benefits: Improved awareness, increased control, and scalability.

  • Downsides: Limited flexibility, manual oversight, margin pressure.

• Rule-Based Processing Stage:

  • Benefits: Higher accuracy, cost control, improved compliance.

  • Downsides: Increased complexity, resource-intensive, system limitations.

• Advanced Data-Driven Processing Stage:

  • Benefits: Predictive accuracy, real-time insights, enhanced customer insights, fraud prevention, conversion optimization, cost management, and strategic decision-making.

  • Downsides: High complexity, significant investment, continuous maintenance.

How Do You Start Going Through The Different Stages?

Now that we have a good understanding of the Stages a PSP or Acquirer goes through when they should go through them, and the benefits and downsides of advancing to each level, let’s have a high-level overview of what taking entails.

In the Initial Awareness Stage, ISOs and/or PSPs often have little insight into how the Exchange rates and Scheme fees are calculated. Therefore, the calculation tends to stop at the type of pricing they have been provided.

For example, an ISO/PSP who has received pricing of:

• 1.5% + €0.25 for domestic and intra-regional transactions,

• and 3.25% + €0.25 for interregional transactions.

I would go about implementing that in the following way.

As the pricing is very simplified, otherwise known as Blended Pricing, calculating those fees is relatively simple.

In this particular case, we would only need three input variables:

1. Transaction Amount (let’s assume we do everything in one currency for now)

2. Issuer Country Code

3. Acquirer Country Code

With these three input variables, we can determine:

• Regionality

This will allow us to calculate the applicable Transaction Costs, which we have “hard-coded” in our logic.

The Transaction Amount is the amount paid by the customer, which any Acquirer will report, as that is the most essential variable.

The Issuer Country Code, is the country code assigned to the Issuer who provided the customer with their card, this data sits within the BIN tables, which the Acquirer extracts when processing the transaction, and will send along in the reporting as a form of proof of as to why they applied a particular fee.

The Acquirer Country Code is the country code assigned to an Acquirer when they get their Acquiring License from the Scheme. Often, that is the country where their Headquarters is established, but as some Acquirers have multiple entities and licenses globally, this could differ ( but for this example, we are going to keep it simple).

To calculate the applicable fees, we first need to determine Regionality.

We do this by checking the Issuer Country Code against the Acquirer Country Code.

• If they are the same, this means we have a: Domestic transaction (UK Issuer AND UK Acquirer)

• If they are different but in the same region, we have an: Intra-Regional transaction (NL Issuer AND FR Acquirer)

• If they are different and in two different regions we have an: Inter-Regional transaction (NL Issuer and US Acquirer)

For this example, we have a European PSP based in an EEA country.

We create a list of EEA countries, which are countries that would fall under the requirement of being an Intra-regional transaction, otherwise known as an Intra-EEA transaction.

Using the input variables we have received, we check the Issuer Country Code against the Acquirer Country Code to determine the Regionality (or as seen in the code Transaction Type).

Based on the output, we can then calculate the fees associated to this transaction.

• If it is domestic or intra-regional, we get 1.5% + €0.25.

• Otherwise (else), we get 3.25% + €0.25 for interregional transactions.

Using the amount variable, let’s say €100,-

We would get:

• €1.50 + €0.25 = €1.75 in transaction costs for domestic and intra-regional transactions

• Or €3.25 + €0.25 = €3.50 in transaction costs for interregional transactions.

Why Do Most ISO’s and PSPs Stay Stuck At This Level

If you have ever written any code, or even if you have created a simple Excel spreadsheet, you would understand that this is the most basic type of implementation you can do.

So why do so many ISOs and PSPs stay stuck at this level?

This comes back to how, in the Payments Industry, we have created a level of Simplicity to deal with the levels of complexity that sit underneath it.

A small Merchant can use simple Blended Pricing to project what type of impact processing payments would have on their Profit & Loss statement.

The ISOs and PSPs who engage with these merchants use a similar simplicity, as they are offered a Blended Buy Rate.

They can effortlessly project their profit margin based on each transaction or the overall volume they are processing.

For the Acquirers offering the Buy-Rates to the ISOs and PSPs, their models are more based on the size of their portfolio, the risk, and the Acquirer Mark-up they aim to achieve.

For Acquirers it is much easier, to aggregate all of their Interchange and Scheme Fee costs, and add an Acquirer Mark-up on top of it, to create their own projections of revenue and profits.

Simplicity Leads to Complacency, which Leads to Mistakes

Having spent the majority of my 20-year career in Payments, developing reporting and analytics and better systems to provide deeper insights into this complexity, I believe that this simplicity has led to so much complacency and mistakes.

Because ISOs and PSPs lack the data required to build better calculations, they tend to become complacent and focus on selling more, always trying to negotiate rates.

Acquirers have also become complacent, relying on third-party legacy players to calculate their fees and using Excel spreadsheets to manage their margins.

The downside of this is that as the Payments industry continues to evolve, and the Schemes continue to introduce new Scheme Fees, change Interchange rates based on changes in regulations, or try to compete against Alternative Payment Methods and Local Schemes, the parties that have to deal with it end up making more mistakes.

The providers to Acquirers can’t really change their underlying technology or need 6 to 12-month projects to do so.

This leads to faulty calculations, which affect Acquirers' bottom lines. Causing them to raise their fees to (either transparently or secretively) without providing proper justification for their ISOs and PSPs.

Next Newsletter

While I could easily write about every single stage and what happens, I feel that this is enough for one newsletter.

In the next edition, I will explore a bit more how PSPs and Acquirers offering Qualified or Interchange Plus models require more data to develop more accurate models.

Thank You for Reading. Feel free to Like, Comment, Share, or Post on Your Socials, as I appreciate all the feedback I can get.

---

P.S. Whenever you're ready, this is how I can help you:

1-on-1 Video Call with Dwayne Gefferie: If you want to solve your Payments challenge quickly, get direct answers based on 20 years of experience and continuous market research, develop a Strategy, validate your idea, or discuss a product feature. Book a 1-on-1 Video with me. [Limited Available Slots].

If you want to work with me in a larger capacity, either speaking, advisory, or consulting, feel free to email or DM me.