The Missing Layer

Every payment institution starts with a gateway. It processes transactions. It shows volumes, approval rates, chargebacks. Normally it would also have a client-facing front, showing the information that is relevant to a merchant.

But does it really show what is due to be paid to the merchant, or what has been earned last month?

Normally, the gateway knows what was processed. It doesn't know what was earned. It doesn't calculate scheme fees, interchange, or net margin per merchant. It doesn't track settlement obligations, rolling reserves, or safeguarding positions. It doesn't produce a trial balance, a P&L by product line, or a regulatory report.

This is the missing layer – and it's where most payment institutions stumble.

A recent gateway review for a European EMI showed a familiar story. The platform was robust: flexible merchant setup, good transaction data, solid routing. But when the question turned to settlements, the answer was: "That happens outside the system." FX: "Not part of the system." Reconciliation: "Manual." IC++ pricing: "Not supported."

The gateway was doing its job – processing payments. But what is critical for a new acquirer is to understand that the layer between processing and finance is crucial. Everything downstream – settlement calculation, fee allocation, safeguarding splits, merchant statements, regulatory reporting – will otherwise be manual, fragmented, or simply not happening.

A settlement engine – or whatever one chooses to call it – sits between the gateway and the accounting system. It takes raw transaction data and transforms it into financial information. Specifically:

It calculates what is owed to each merchant, net of fees, in the correct currency, on the correct settlement cycle. It splits scheme fees (interchange, assessment, processing) from gross revenue to determine actual margin and, in this case, support the IC++ method of fee billing. It handles FX – because if a merchant processes in GBP but settles in EUR, someone needs to manage that conversion and the margin on it. Even more crucial if there are rolling reserves – because then, the split between client funds, earned revenue, and reserves must be calculated per settlement run, not estimated at month end.

Without this layer, finance teams are manually recreating all of the above in spreadsheets. Every day. From raw data exports. With formulas that nobody else understands and that break when a new merchant or currency is added.

Let's hope the settlement engine exists and works flawlessly, and settlements to merchants are happening in a fully automated regime. But is the ERP system keeping track? And does it export reports that are up to date, for the regulator, management, and auditor? Is the chart of accounts designed in a way that is representative of the nature of a financial institution, or are we squeezing merchant balances into trade payables? Is the optimal synchronisation of the systems set up, to avoid data mismatches and reporting delays?

Although the accounting layer is just keeping tabs on what happened within the business, proper records and robust data – and therefore, proper setup for the integration with the business modules – shall not be overlooked. Keeping the records accurate and clean helps on many layers: the finance team will report business information based on the information available to them, and the business will be taking decisions based on that. The regulators and the auditors conclude on the health of the business based on the same records.

So now there are three systems that need to talk to each other: gateway, settlement engine, and ERP. Add a core banking system for issuing or account management, and there are four.

The question isn't "what software should we buy." The question is: "What data needs to flow between these systems, in what format, at what frequency, and who is responsible for reconciling the gaps?"

That's an operational architecture question. Not only a CTO question. It's a question about how the business produces reliable financial information from raw transaction data – and it needs to be answered by someone who understands both the payment flows and the accounting standards.

When finance spends more time chasing data than analysing it, the missing layer is the problem. Build it once, build it right, and finance becomes a function that generates insight instead of fighting for accuracy.