Reconciliation System

Settlement and Revenue Analysis System

Home > Portfolio > Settlement and Revenue Analysis System

Turning raw switch transaction data into accurate, auditable revenue insight

A settlement and revenue analysis platform built for SWITCH providers to calculate revenue generated from MasterCard, VISA, and UPI transactions — along with other digital transaction revenue streams flowing through the switch — giving providers a clear, accurate view of how revenue was actually being generated across networks, transaction types, and card issuers.

The system was built to address a problem that's easy to underestimate until it's audited: a switch provider sits at the intersection of multiple card networks and other digital transaction streams, each with its own fee structures and settlement rules, and without a system built to reconcile that complexity down to the GL level, revenue numbers become an estimate instead of a fact.

Key metrics

Revenue calculation across MasterCard, VISA, and UPI transaction networks, plus other digital transaction revenue streams
Breakdown by transaction type, card issuer, and revenue source
Full transaction settlement with GL-level accounting, managing 200+ GL categories
Direct integration with a central bank API for real-time forex rates
Full audit logging of settlement and revenue calculations
Fully automated settlement across 12+ banks on a standardized process, requiring no manual intervention

Context

A SWITCH provider doesn't process transactions for one card network — it sits in the middle of several, each with its own fee schedules, interchange rules, and settlement mechanics. MasterCard, VISA, and UPI transactions don't just differ in branding; they differ in how revenue is actually generated and how that revenue needs to be calculated and reported. And network fees aren't the only revenue in play — providers also generate income from other digital transaction activity flowing through the switch, each with its own logic for how that revenue is earned and attributed.

On top of that, cross-border and cross-currency transactions introduce a moving target: revenue calculated at one forex rate can look meaningfully different by the time settlement actually happens, if that rate isn't sourced accurately and consistently.

Without a system purpose-built for this, providers were left reconciling revenue across networks manually or through disconnected reports — a process that made it hard to answer a question that should have been simple: how much revenue did we actually generate, broken down by network, transaction type, and issuer, and can we prove it?

The Challenge

The core challenge wasn't calculating a fee — it was building a system that could calculate revenue correctly and consistently across multiple card networks and other digital revenue streams with different rules, apply accurate real-time forex conversion where currencies crossed, fully settle every transaction with proper GL-level accounting, and keep a defensible record of exactly how every number was derived.

This meant the system needed to:

Support revenue calculation logic specific to MasterCard, VISA, and UPI individually, as well as other digital transaction revenue streams outside the three major networks.
Break revenue down by transaction type and card issuer, not just as an aggregate total.
Source accurate, real-time forex rates for cross-currency transactions.
Keep detailed logs of settlement and revenue calculations for audit and dispute purposes.
Perform full settlement of every transaction with proper accounting against the correct GLs — across more than 200 GL categories.
Stay accurate as network fee structures and rules changed over time.
Standardize settlement so it wasn't built bank-by-bank, but fully configurable to onboard a new bank without new development.
Present revenue insight in a way that let providers actually act on it, not just view it.

In effect, the system needed to function less like a reporting dashboard and more like a settlement engine with reporting as its output — every number, and every GL posting, traceable back to the transaction, network rule, and forex rate that produced it.

My Role

I was responsible for the architecture and development of the platform, with ownership spanning revenue calculation logic, GL-level settlement, forex integration, and audit logging.

My work included:

Designing the revenue calculation architecture across MasterCard, VISA, UPI, and other digital transaction revenue streams.
Building network-specific rule logic for interchange and settlement-related revenue calculation.
Integrating with the central bank's API for real-time forex rates on cross-currency transactions.
Designing the transaction-type and issuer-level breakdown and reporting layer.
Designing the settlement engine's GL-level accounting logic across 200+ GL categories.
Implementing audit logging for settlement and revenue calculations.
Designing the system to accommodate rule and fee-structure changes per network without requiring a rebuild.

The key architectural responsibility was making sure every revenue figure the system produced could be traced back to the specific transaction, network rule, and forex rate that generated it — so the numbers weren't just accurate, they were defensible.

Engineering Challenges

Reconciling different revenue logic across networks and channels in one system

MasterCard, VISA, and UPI each calculate revenue differently, and those rules aren't static — they change. On top of that, other digital transaction activity outside the three major networks generated revenue under its own logic entirely. Building a system that could apply source-specific logic without turning into a growing pile of disconnected calculators meant designing a rule engine that treated each revenue source's logic as a configurable layer feeding into one common revenue model, rather than hard-coding calculation logic per source throughout the system.

Keeping forex-driven revenue accurate, not approximate

Revenue on cross-currency transactions is only as accurate as the exchange rate applied to it. Integrating directly with the central bank's API meant the system could use the actual applicable rate rather than a cached or delayed one — but it also meant handling rate-fetch timing carefully, since revenue calculated against the wrong moment's rate is a different, wrong number, not a rounding error.

Making every number traceable after the fact

A revenue figure that can't be explained isn't useful in a settlement context — disputes and audits require showing exactly how a number was derived. Logging settlement and revenue calculations in enough detail to reconstruct that derivation later, without the logging itself becoming a performance or storage burden at transaction volume, was a core design constraint rather than an afterthought.

Breaking revenue down without losing accuracy

Aggregate revenue is easy to get right; revenue broken down by transaction type and issuer is much easier to get subtly wrong, since misattributing even a small share of transactions can distort the breakdown even if the total stays correct. The attribution logic had to be accurate at the individual transaction level for the breakdown to actually be trustworthy, not just the total.

Settling accurately across 200+ GL categories

Revenue reporting is only as trustworthy as the settlement underneath it. Every transaction had to be fully settled with debits and credits posted against the correct GLs, across more than 200 GL categories spanning different networks, revenue streams, and transaction components. Getting this wrong wouldn't just produce a bad report — it would mean the books themselves were inaccurate. That meant GL attribution logic had to be as rigorously correct as the revenue calculation itself, and the two had to stay consistent with each other rather than being maintained as separate systems that could quietly drift apart.

Standardizing and fully automating settlement across 12+ banks

Different banks tend to have different settlement conventions, formats, and expectations, which easily pushes a system toward maintaining separate logic per institution — and often toward manual steps to bridge the gaps between them. Instead, settlement was standardized into a single consistent process capable of running fully automatically across 12+ banks, with no manual intervention required at any stage. That meant designing the settlement logic around what was common across institutions and treating bank-specific differences as configuration rather than separate code paths or manual workarounds, so adding another bank didn't mean building another settlement pipeline or introducing a new manual step.

Reflection

This project changed how I think about financial reporting systems. It's easy to treat "calculate revenue" as a math problem — apply a fee, sum it up. In a multi-network, multi-stream settlement context, the harder problem is that the math itself isn't one formula, it's dozens of different formulas that all have to be applied correctly, consistently, and traceably — against data that includes a moving target like forex rates, and results that ultimately have to land as correct debits and credits across 200+ GL categories, not just a number on a dashboard.

The real engineering work wasn't the revenue calculation itself — it was building a system where every number, and every GL posting behind it, could stand on its own if someone asked "how did you get this?" That's the standard I now hold financial reporting and settlement systems to: not just correct, but provably correct.

Get In touch

Feel free to email me at hi@riteshr.com.np for counsuting work, and I'll get back to you.