Portfolio · Settlement · Revenue

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.

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

Key Capabilities

Settlement that explains where every revenue figure came from.

Revenue calculation across MasterCard, VISA, and UPI networks, together with other digital transaction revenue streams.

Revenue breakdown by transaction type, card issuer, network, and revenue source.

Full transaction settlement with GL-level accounting across more than 200 GL categories.

Direct integration with a central bank API for real-time foreign exchange rates.

Full audit logging of settlement and revenue calculations.

Fully automated settlement across 12+ banks through a standardized process requiring no manual intervention.

Settlement and Revenue Analysis System interface

Context

Why this system was needed.

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.

Network fees also weren't the only revenue source involved. Providers generated income from other digital transaction activity flowing through the switch, each with its own logic for how revenue was earned and attributed.

Cross-border and cross-currency transactions added another layer of complexity. Revenue calculated against the wrong foreign exchange rate could produce a materially different settlement result.

Without a system purpose-built for this, providers were left reconciling revenue across networks manually or through disconnected reports — making it difficult to answer a question that should have been simple: how much revenue did we actually generate, where did it come from, and can we prove it?

The Challenge

The challenge wasn't calculating one fee.

The real challenge 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, settle every transaction with proper GL-level accounting, and maintain a defensible record of exactly how every result was derived.

Apply network-specific revenue rules

MasterCard, VISA, UPI, and other digital transaction streams each needed their own calculation logic without fragmenting the system into separate calculators.

Break revenue down accurately

Revenue needed to be attributable at transaction type, issuer, network, and revenue-source level rather than existing only as an aggregate total.

Apply real-time forex rates

Cross-currency revenue calculations required the correct exchange rate at the relevant point in settlement rather than relying on stale or manually maintained values.

Settle against the correct GLs

Every transaction needed proper debit and credit treatment across more than 200 GL categories spanning networks, transaction types, and revenue components.

Preserve a complete audit trail

Every calculated revenue figure and settlement posting needed to be traceable back to the transaction, rule, and exchange rate that produced it.

Standardize settlement across banks

Bank-specific differences needed to become configuration rather than separate code paths so new institutions could be onboarded without creating another settlement implementation.

Settlement and revenue reporting interface

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

Settlement architecture and financial calculation logic.

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.

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 API for real-time foreign exchange rates on cross-currency transactions.

Designing transaction-type and issuer-level revenue breakdown and reporting.

Designing the settlement engine's GL-level accounting logic across more than 200 GL categories.

Implementing audit logging for settlement and revenue calculations.

Designing the system to accommodate network rule and fee-structure changes 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 simply accurate, they were defensible.

Engineering Challenges

Where the complexity actually lived.

Challenge 01

Reconciling different revenue logic in one system

MasterCard, VISA, UPI, and other revenue streams each followed different and changing rules. A configurable rule engine allowed source-specific logic to feed one common revenue model instead of spreading hard-coded calculation rules throughout the platform.

Challenge 02

Keeping forex-driven revenue accurate

Cross-currency revenue is only as accurate as the rate applied to it. Integrating directly with the central bank API reduced reliance on stale rates, while timing had to be handled carefully because using the wrong rate produces a different financial result, not just a rounding difference.

Challenge 03

Making every number traceable afterward

Settlement disputes and audits required the system to reconstruct exactly how a result had been calculated. Logging therefore had to preserve the transaction, calculation logic, rates, and settlement details without becoming a performance burden at transaction volume.

Challenge 04

Breaking revenue down without losing accuracy

Aggregate totals can remain correct even when individual transactions are attributed incorrectly. Revenue therefore had to be classified correctly at transaction level before issuer, transaction-type, or network-level analysis could be trusted.

Challenge 05

Settling accurately across 200+ GL categories

Revenue reporting was only as trustworthy as the settlement underneath it. Every transaction had to post debits and credits against the correct GL categories, and the GL attribution logic had to stay consistent with the revenue calculation so accounting and reporting could not silently drift apart.

Challenge 06

Fully automating settlement across 12+ banks

Different institutions had their own settlement conventions and expectations. The solution standardized the common settlement process and moved institution-specific differences into configuration, allowing the same engine to operate automatically across more than 12 banks without manual intervention or separate pipelines.

Reflection

Financial reporting should be provably correct, not merely plausible.

This project changed how I think about financial reporting systems. It's easy to treat “calculate revenue” as a math problem — apply a fee and sum the result.

In a multi-network, multi-stream settlement environment, the difficult part is that the math isn't one formula. It's many different formulas applied under different rules, against data that can depend on moving inputs such as forex rates.

And those results ultimately have to become correct debits and credits across more than 200 GL categories, not simply numbers on a dashboard.

The real engineering work was building a system where every revenue figure and every GL posting 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.