Treasury Visibility When Your Platform Uses Multiple Banks

Most growing fintech platforms reach a point where they are operating bank accounts with two or three institutions simultaneously. There is the primary account for operational payments, an escrow or segregated account for customer funds under regulatory requirements, and perhaps a third account with a different bank for specific payment corridors or currency denominations. Each account has its own balance, its own transaction history, and its own portal or API.

At that point, a question that should be simple becomes genuinely difficult: what is our total available cash position right now? The answer requires pulling information from three different sources, each with its own latency and data format, and aggregating it into a single number. For many teams, this involves logging into multiple bank portals, exporting data, and running the aggregation in a spreadsheet. The result is a cash position that is accurate as of several hours ago at best.

Why Treasury Visibility Degrades as Provider Count Increases

The degradation is structural. Each bank provides its own balance API or portal, and the data from each source has different characteristics: different refresh frequencies, different timestamp formats, different ways of representing pending versus settled transactions, and different conventions for what "available balance" means versus "ledger balance."

DBS's API returns balance data that distinguishes between book balance and available balance, where the difference includes holds and deductions not yet posted. A FAST payment received after 10 PM may appear in the book balance but not yet in the available balance for same-day use. A cross-border wire in progress appears in neither until settlement confirms. Each of these distinctions is encoded differently across providers, and building a unified view requires understanding the semantics of each data source.

When teams build this aggregation themselves, they typically produce something that works for the primary use case (daily cash position review) but breaks down at the edges: intraday visibility during high-volume periods, reconciliation-time balance checks, or projections of future cash position based on pending payment flows.

The Practical Cost of Poor Treasury Visibility

Poor treasury visibility is not an abstract problem. It shows up in specific operational situations.

The most common is delayed vendor or partner payment decisions. When a finance team cannot quickly determine whether available cash across all accounts covers a pending obligation, they delay the decision until they can get a reliable number. For a platform with routine high-value outflows (payouts to marketplace sellers, bulk payroll processing, partner settlement), this delay compounds across many decisions per week.

The second situation is regulatory reporting under MAS. Platforms with payment institution licenses have reporting obligations that include data about customer funds held in segregated accounts. If the platform's visibility into segregated account balances is delayed or requires manual aggregation, the accuracy and timeliness of that reporting is at risk. MAS reporting requirements are not flexible about timing; the obligation is to have accurate data available when it is needed, not after the next manual export.

The third situation is cash management efficiency. A platform with $400,000 spread across three bank accounts but without real-time visibility may keep more in each account as a buffer than necessary, because the finance team cannot quickly determine when to sweep funds between accounts. The inefficiency is not large per instance, but it compounds over time as an opportunity cost on idle cash that could be earning treasury returns or reducing outstanding credit facilities.

What a Unified Treasury Data Model Requires

Building useful treasury visibility requires solving a few distinct problems. Understanding these separately makes the architecture decisions cleaner.

The first problem is data normalization. Each bank's API or data export uses its own schema. A unified model needs to abstract over these: a standardized balance record that captures available balance, ledger balance, pending inflows, pending outflows, and the timestamp of the last update, regardless of which bank produced it. This normalization layer is straightforward to build, but it requires maintaining integrations with each bank as their APIs evolve.

The second problem is latency alignment. Different banks refresh balance data on different schedules. Some offer real-time webhooks on transaction events. Others offer near-real-time polling APIs. Others still rely on end-of-day batch files. A unified view needs to represent the freshness of each balance source, not just present a number without context. A balance that was refreshed 30 seconds ago and a balance that was refreshed 8 hours ago are not interchangeable for operational decisions.

The third problem is transaction attribution. When funds move between accounts or when a payment is processed, you need to be able to trace the movement across your treasury model. A payout that draws from account A and is settled to a customer's bank via provider B should appear as a debit in account A's ledger and as a completed transaction in the routing layer. Without this attribution, cash position analytics are disconnected from payment flow analytics, and you lose the ability to understand why your cash position changed.

Where the Payment Layer Fits

The payment routing layer is a natural anchor for treasury data because it is the record of every payment decision. It knows which account each transaction drew from, which provider processed it, and what the expected settlement is. When treasury visibility is built on top of routing data, you get attribution automatically: the balance change is explained by the transactions that caused it.

This is the design Checker uses internally and that we expose to platforms using the API. Every payment routed through Checker produces a transaction record that includes the source account, the provider assignment, and the expected settlement timing. Treasury reporting queries this record set to aggregate positions across accounts. The position is derived from payment events, not from polling bank balances directly, which means it is as fresh as the last transaction event rather than as fresh as the last bank API refresh.

There is an important nuance here. Payment event-derived treasury position tells you about the payments layer of your balance. It does not capture things that happen outside the payments layer: direct bank transfers, interest postings, bank fee deductions. For a complete treasury picture, you need both: the payment layer view for transaction-driven changes, and the bank API view for non-payment changes. The bank API view catches the residual; the payment layer view provides the granularity.

The Specific Case of Segregated Customer Funds

For Singapore platforms with payment institution licenses, the regulatory requirement to hold customer funds in segregated accounts adds a specific treasury management dimension. MAS requirements under the Payment Services Act specify that customer money must be held separately from business funds and in qualifying institutions. The finance team needs to maintain visibility into segregated account balances to ensure they are always sufficient to cover customer liabilities.

This is a place where poor treasury visibility creates direct regulatory risk. If the segregated account balance falls below the aggregate of outstanding customer fund liabilities due to a timing mismatch (a large inflow is pending but not yet settled, while outflows have already processed), the platform may be technically in breach of the segregation requirement during the gap period, even if it is resolved within hours.

Real-time visibility into segregated balances, combined with visibility into pending inflows from the routing layer, allows the finance team to monitor this exposure continuously and act before a gap occurs rather than discovering it in the next day's balance report.

Building Versus Using Infrastructure

The natural question for a platform team is: should we build this visibility layer, or should we use infrastructure that already has it? For a team of two or three engineers where payment infrastructure is not the core product, building and maintaining a multi-bank balance aggregation and normalization layer is an ongoing cost that scales with provider count. Each bank relationship adds integration maintenance. Each API version change requires an engineering response.

Using an orchestration layer that has already solved the normalization and attribution problems shifts that maintenance cost to the infrastructure provider. The trade is access to treasury visibility that scales as provider count grows, without engineering overhead that scales proportionally. For teams where engineering time is constrained, that trade is usually worth examining carefully before committing to a build-it-yourself approach.

The question to answer honestly is whether multi-bank treasury visibility is a capability your team will continuously invest in improving, or a capability you need to have working reliably so you can focus elsewhere. The answer shapes the build-versus-use decision.