How To Build A Predictive Interchange & Scheme Fee Framework

So you can accurately calculate Interchange & Scheme Fees like the Top Acquirers

In the last few weeks, I have shared how ISOs and PSPs deal with pricing models in payments. I have explained that by introducing the Interchange & Scheme Fees Capability Maturity Model. The level that is rarely discussed is that of the acquirer.

The reason it isn’t discussed as often is because most acquirers THINK they know how it works by reverse engineering it, as I discussed in the previous newsletter, instead of understanding how it works.

Most acquirers base Interchange and Scheme Fee calculations on published rates and reverse engineer them instead of taking the time to truly understand the manuals, which give a pretty accurate guide on how it actually explains how it works.

In this newsletter, I will explain how to build a predictive interchange and scheme fee framework that is not based on spaghetti code but rather a system that allows an acquirer to maintain it seamlessly, stores data so it can be reviewed for accuracy, is flexible, and can handle complex criteria and fee structures.

Let me explain…

The Reason Framework-Based Systems Are Better Than Ad-hoc Logic

Payments is a legacy system-based industry.

I continue to say that, because when we look at what is actually underneath the shiny facades of the websites and social media platforms we use, we can quickly see that the systems they run on are built with ad hoc logic.

Ad-hoc logic occurs when platforms are built with code that is reactive to external changes and apply ad-hoc fixes to the platform to deal with them, in the form of code that recreates the logic steps that need to be taken.

For example, in the last few years, we have been introduced to several new concepts, such as 3DS, Tokenization, and P2P.

These products have often been reactions to industry trends, which in most cases involve fraud, security, or regulations. In the case of P2P, they are trying to fix inefficiency by creating a newer and faster way of moving money.

But instead of redesigning the entire platform, companies choose to let developers add some additional code to the existing codebase, and as long as it doesn’t break, it is deemed a success.

The reason most payments companies do this is simple.

In most cases, the expertise is just not available.

Either the core developers who built the original system have left or are needed for much more important development work.

Furthermore, as companies grow, resources become constrained, as they are much more needed to maintain the status quo than to rebuild something that “still works.”

However, as systems must be much more adaptable in 2024 and beyond, payments companies must transition from ad-hoc logic to a systematic, framework-based approach to improve efficiency, maintainability, scalability, and flexibility.

But instead of philosophizing about it, why don’t I show you?

For example, I’ll show you how to build a framework-based system and determine and calculate interchange and scheme fee rates in a payment platform.

More specifically, I will do it from the perspective of an Acquirer.

Where Do Most Acquirers Start

As I shared in the previous two editions of this newsletter, most Acquirers are actually evolutions of either ISOs (Independent Sales Organizations) or PSPs (Payments Service Providers), which have grown big enough that the natural evolution for them is to become Principal Members with the Card Schemes MasterCard and Visa.

However, to do so, they must decide between renting or building their Cards Processing Engine.

Most still choose to rent, believing that is the fastest way to get to market. This is especially true if you realize that very few people in the world actually understand all the components necessary to build a Card Processing Engine.

However, as these companies become Acquirers, they now also have to deal with the complexity that goes with it, which means genuinely understanding Interchange and Scheme Fees.

And this is where so many companies go wrong.

They are under the false belief that Interchange and Scheme Fees are just a financial component of what they are trying to do.

So, very quickly, analysts or accountants are brought in to create the Pivot Table of DEATH.

Instead of understanding how Interchange and Scheme Fees actually work, these analysts start creating rate tables, adding fee descriptors to them, and assuming criteria.

If you are operating in a single country, this might be doable, but if you are anything like the thousands of principal member acquirers worldwide, your ambitions are much bigger than that.

The result is that suddenly, these spreadsheets contain thousands of single rules, trying to deconstruct how a fee is selected.

Where Should Acquirers Start Instead?

Instead, acquirers should THINK like technology companies and actually build scalable systems designed to handle increasing complexity.

Let me show you.

For this example, I will focus just on VISA and their Interchange.

Interchange Fee Program Algorithm

To determine which VISA Interchange rate needs to be applied to a particular transaction, the Acquirer needs to run an algorithm in which they:

• collect the relevant data,

• pre-process certain input variables,

• filter through hundreds of programs based on criteria,

• take the eligible fee programs and calculate the outcome,

• compare the total fees,

• select the lowest fee, and

• update the transaction data table to reflect the calculation.

See the image below for the steps.

TransactionData: Deconstructing Data for Efficient Processing

Whereas ad-hoc logic would process the data by running a simple program and applying fees based on input variables, systems can run concurrently when designing a systemized process.

For the example above, TransactionData is crucial data that ensures an efficient and effortless process flow.

Here's how the TransactionData process works:

1. The process starts with extracting relevant fields from the authorization and clearing data.

2. This data is then stored in a structured format in the TransactionData table.

3. The system queries the FeeProgram_Criteria table to determine eligible fee programs based on the transaction data.

4. For each eligible fee program:

   • The system calculates the total fee

   • It queries the FeeProgram_Rates table for applicable rates

   • It applies these rates and calculates the fee

5. The system then compares the fees calculated for all eligible programs.

6. The program with the lowest total fee is selected.

7. The selected fee program is applied to the transaction.

8. The TransactionData table is updated with the results.

See the image below for the data model and how it connects to the different tables.

This data model includes three main tables that will be part of the interchange fee calculation process:

1. TransactionData

   • This table stores all the relevant information about each transaction.

   • It includes fields such as merchant category code, POS entry mode, card type, transaction type, geography, fee program indicator, and reimbursement attribute.

   • The transaction_details field (JSON type) allows for storing additional transaction-specific data that might be needed for fee calculations.

   • calculated_fee stores the final calculated fee for the transaction.

   • applied_fee_program_id is a foreign key referencing the fee program that was ultimately applied.

2. FeeProgram_Criteria

   • This table stores the criteria for each fee program.

   • The eligibility_criteria field (JSON type) allows for flexible storage of various conditions that determine when a fee program applies.

3. FeeProgram_Rates

   • This table stores the actual rates for each fee program.

   • It includes fields for base_rate and percentage_rate.

   • The tiered_rates field (JSON type) allows for the storage of more complex rate structures that might depend on transaction volume or other factors.

Using TransactionData to Determine The Fee Program

So now that we understand that instead of using an ad hoc logic approach to assessing which fees apply, we need an Interchange Fee Program Algorithm that guides us through the steps. We also know what data we need to collect from the authorization, clearing, and settlement process. All that remains is to use that data to help us find the correct Exchange Fee Program.

To do that, we are going to take the TransactionData and pre-process it to get the results we need to filter it through the Fee Program Criteria.

Here is an overview of the steps that need to be taken.

1. Jurisdiction Determination:

   • Based on Visa's rules, we set the parameters for what is Domestic, Intraregional, or Interregional. We run a function that inputs the issuer, merchant, and acquirer locations and, in specific cases, the MCC to determine if it is an airline.

2. Interchange Fee Schedule Selection:

   • Based on the jurisdiction and transaction type, select the appropriate interchange fee schedule (e.g., POS, Cash Disbursements, Original Credit, Interlink).

3. Product Identification:

   • Determine the card's Account Funding Source (AFS) and Product ID (PID) combination (e.g. Visa Signature Credit or Visa Business Debit).

4. Fee Program Indicator (FPI) Processing:

   • For applicable regions, extract the FPI from the transaction data

5. Reimbursement Attribute:

   • Extract the Reimbursement Attribute from the transaction data

6. Data Element Extraction:

   • Extract other relevant data elements such as Merchant Category Code (MCC), POS Entry Mode, Authorization Characteristics Indicator, etc.

7. Fee Program Eligibility Check:

   • Using the extracted data, check eligibility against each fee program's criteria.

8. Fee Calculation:

   • For each eligible fee program, calculate the fee using rates stored in a FeeProgram_Rates table.

9. Special Program Checks:

   • Implement checks for special programs like the Visa Partner Program (VPP) or Global B2B Virtual Payments.

10. Fee Comparison and Selection:

    • Compare the calculated fees for all eligible programs.

    • Select the most appropriate fee (often the lowest, but follow Scheme rules for precedence).

11. Fee Application and Logging:

    • Apply the selected fee program.

    • Log the applied FPI, fee descriptor, and calculated fee amount.

    • Store these results in the TransactionData table.

12. Handling Non-Standard Cases:

    • Implement logic for handling special cases like Mobile Push Payments, ATM transactions, and Original Credit Transactions (OCTs).

13. Visa Claim Resolution (VCR) Handling:

    • For dispute-related transactions, implement logic to apply the same fee as the original transaction or a proportional fee for partial disputes.

As you can see from the steps above, selecting an Exchange is a complicated, multi-step process. It should definitely not be built by creating ad hoc logic but rather by using a systematic framework-based approach.

The Added Bonus: From Ad-Hoc Code to A System with a UI

As I have built this over a dozen times in the last ten years, I continue to iterate on how this should work.

However, the added bonus is that following this approach makes building a User Interface (UI) on top of it very easy.

Through a UI, Card Scheme Managers or Analysts can update the underlying tables, which change constantly, without having to submit a ticket or wait until a developer is available.

The product owner can easily input updates on fee programs, rates, and eligibility criteria.

In the end, the objective of an Interchange & Scheme Fee Framework should be to:

• Be data-driven, allowing for easy updates as Visa changes its fee structures.

• Be flexible and capable of handling complex criteria and fee structures.

• Be maintainable, clearly separating data, criteria, and calculation logic.

• Be scalable and able to handle a growing number of fee programs without changing the core logic.

What’s Next

Does what I just shared give you the entire blueprint for building an Interchange & Scheme Fee Framework?

No, it doesn’t.

But I hope it helps the hundreds (or even thousands) of acquirers I have seen who hide behind the fact that Interchange and Scheme Fees are so complex that they simplify and dumb it down for the merchants, PSPs, and ISOs they work with simply because THEY don’t know how to build the technology for this.

Once you figure this out, the benefits are tremendous, as you will be able to:

• Provide Merchants, PSPs, and ISOs with a 100% accurate calculation of Interchange Rates and Scheme Fees, allowing for more adoption Interchange++ as a Pricing Model

• Provide Financial Teams (Internally) with 100% accurate Passthrough Reporting, including a breakdown of regionality, channels, card type, product type, and so much more, which can be matched with the invoices provided by the Card Schemes.

• Provide Analytics Teams (Internally) with the ability to develop benchmarks and alerts to always stay on top of KPIs, such as Passthrough Rates and Benchmarks.

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

---

P.S. If, for whatever reason, you can’t get enough of me:

Payments Optimization Webinar with WorldPay: If you want to hear me speak about the Strategies I have deployed with leading Merchants, join me and Cindy Turner (CPO of WorldPay), and Brant Peterson (Head of Payment Optimization - WorldPay) for FREE [Limited Available Slots].

MasterCard Digital Safari - Leveraging Acquiring for Strategic Advantage: If you are working at a Payments company that is a Principal Member of MasterCard, I will be speaking at their Digital Safari on August 20th and September 18th. [Principal Members Only].

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.