Partner-held ledgers
End-customer balances live in each fintech's system. The bank receives a file or an API summary.
Banks & BaaS
Each partner program needs its own books, and the bank needs to see all of them.
Sponsor banks and BaaS platforms carry the obligations of many fintech programs at once. Orangepill gives each program isolated financial state and governed execution, while the bank keeps oversight across all of them. It runs alongside your core and your rails; it is not a bank and does not replace one.
The problem
Program growth turns into oversight debt.
Each new fintech partner brings its own ledger, its own payout patterns and its own idea of what a balance means. The bank remains accountable for the funds underneath. Without a shared model, oversight becomes a recurring exercise of collecting reports from partners and comparing them with bank statements.
Typical architecture today
Partners keep the detail. The bank sees the totals.
Pooled settlement accounts
Funds for many end customers sit in shared accounts, and attribution depends on the partner's records being right.
Controls applied after the fact
Limits and program rules are checked in reviews and reports, not at the moment money moves.
Where it breaks
The gaps show up at month end, or in an exam.
- The sum of a partner's reported balances does not match the settlement account.
- A payout exceeds what the program's policy allows, and is caught only in review.
- One partner's incident forces investigation across every program sharing the same accounts.
- Answering "where did this customer's money go" requires the partner's engineers.
Orangepill model
Isolate each program. Govern every movement. Keep the evidence.
Program isolation
Each program and its end customers have their own ledger state and settlement boundaries inside one runtime.
Settlement governance
Program policy is applied before execution, and program ledgers are verified against bank settlement afterwards.
Treasury visibility
The bank sees each program's obligations derived from ledger events, not from the partner's summary.
Orangepill is software infrastructure. It is not a bank, payment service provider, or regulated payment rail. Accounts, licences and settlement remain with the bank and its rails. The runtime governs the financial state and the execution that sit on top of them.
Example workflow
A payout initiated by a fintech partner.
- Partner request On behalf of an end customer
- Program policy Limits, balance, permissions
- Execution Via the bank’s payout rail
- Program ledger Effect recorded for that program only
- Verify Against bank settlement
A request that fails policy never reaches the rail. A request that reaches the rail and returns an unclear outcome becomes a Resolve case scoped to that program, not a bank-wide investigation.
Capabilities used
What carries program governance.
Wallet & Ledger
Separate ledger state per program and per end customer, so one partner’s balances are never derived from another’s entries.
Explore Wallet & Ledger →Execution
Partner-initiated payouts and transfers run as governed lifecycles, with program policy checked before value moves.
Explore Execution →Proof of Record
Structured evidence of how each program-level outcome was produced, ready for oversight and audit questions.
Explore Proof of Record →Resolve
Governs breaks between program ledgers and bank settlement, with authority staying with the bank.
Explore Resolve →Outcome
Oversight that comes from the record, not from requests for reports.
- Onboard a new embedded-finance program without building a new ledger for it.
- Apply program controls at execution time rather than in retrospective review.
- Contain incidents to the program they belong to.
- Trace an end customer's funds without depending on the partner's systems.
- Give audit and oversight teams evidence, not reconstructions.
Map one partner program with us.
Pick a program and its payout path. We will show how its state could be isolated, governed and verified against your settlement accounts.