BaaS Does Not Let the Sponsor Bank Outsource Its Name, Its Ledger or Its Regulator.

Your fintech partner owns the screen.

A valuable thing to own.

It owns the moment a customer needs to be paid, paid out, issued a card, shown a balance, or persuaded to complete yet another identity field while standing in a railway station.

It may own the brand, the push notification, the customer-service tone, and the small carefully rounded button that makes the whole arrangement look as though it sprang fully formed from a product manager’s head.

You own a rather less photogenic collection.

The regulated account.

The deposit liability.

The payment authority.

The compliance obligation.

The regulator’s telephone number.

You cannot contract those away.

You can contract for their performance.

That distinction is the entire programme.

Which becomes important the moment somebody says the funds are with the fintech.

They may be, in the conversational sense that causes trouble later.

In an FBO or omnibus structure, your sponsor bank holds a pooled deposit and its ledger records the aggregate liability.

The programme ledger allocates that pool among end customers.

The app displays the allocation.

A processor reports the payment state.

All perfectly normal.

It becomes exciting only when one record is asked to certify a fact owned by another.

So the working question is not who owns the source of truth. That phrase has done rather well for itself in meetings and almost no work in operations.

Which institution is authoritative for which fact, and how do the records meet at the hand-off?

The App Is the Lobby, Not the Bank

Start at your account opening.

Your customer enters personal details, consents to the app terms, supplies identity evidence, and selects one of your accounts.

A programme manager may collect and validate those inputs.

It may run fraud filters, sanctions processes and customer service.

It may have a better interface than the bank.

Not difficult.

Also not a transfer of authority.

You decide whether to open the account, place the customer in a pooled arrangement, or reject the relationship.

Your decision creates a bank customer identifier, or a relationship to an omnibus account.

The programme creates its own customer identifier.

A processor frequently adds another.

The FBO account has an identifier too.

So your identity crosswalk is four records long.

Bank customer ID.

Programme ID.

FBO or omnibus account ID.

Payment credentials.

A 16-digit card number identifies a payment instrument.

It does not establish beneficial ownership of your pooled balance.

Cards have many virtues. Conveyancing is not among them.

The role map has to go beyond the names on an org chart.

It identifies the legal customer, the sponsor bank, the programme manager, the FBO account, the end-customer ledger, the available-balance calculation, the safeguarding status, the reconciliation time, the KYC owner, the transaction monitor, and the escalation authority.

That is the complete set of programme-account controls.

The partner owns onboarding is a commercial summary. It is not a control description.

Nor is this fastidiousness confined to launch.

The interagency guidance frames third-party risk management as five stages.

Planning.

Due diligence and selection.

Contract negotiation.

Ongoing monitoring.

Termination.

Your diligence file is not a life cycle, however handsomely tabbed.

Your sponsor bank needs to know whether fraud, complaints, ledger breaks, customer impact, data access and dependence on a middleware provider are changing during the relationship.

Not merely whether the introductory deck had reassuring fonts.

One Receipt, Three Different Facts

Suppose an outside bank sends $500.

Settlement delivers the money to you, perhaps into an account titled for the benefit of programme customers.

Your deposit ledger records a $500 increase in what you owe in that account.

That is authoritative about how much cash you hold.

It is not authoritative about which end customer is owed what.

The programme receives an event and posts $500 to its customer subledger. The app may present the amount as available, subject to its funds-availability and risk rules.

That status needs more discipline than a cheerful tick mark.

Received, cleared, settled and available are distinct fields, because they describe distinct things.

A credit that can still be returned is not safely spendable because the animation has finished.

Where the money sits in an FBO arrangement, your allocation record needs the event ID, the source, the effective date, the account mapping, the amount in dollars and cents, and an immutable link to any later reversal or adjustment.

FDIC Part 370 applies to insured depository institutions with 2 million or more deposit accounts for 2 consecutive quarters.

It is not a universal subledger prescription.

It does state the institutional preference with admirable clarity.

An institution should be able to calculate insured and uninsured amounts from maintained information.

Not from a retrieval expedition after the building has become interesting.

The account agreement, the account titling and the maintained records are what make an allocation meaningful.

They are what keep an FBO balance from becoming decorative fiction. A large number in one system, surrounded by much customer affection and no demonstrable claim.

Available Is a Permission, Not a Number

Now your customer sends $120 out.

Before authorisation, the programme decides whether $120 is available.

The calculation starts with the subledger balance, then takes account of holds, pending debits, relevant chargeback exposure, fees, blocks, the bank’s balance and risk limits.

A cached response that said $500 a few seconds ago is not a payment-control policy, however promptly it returns JSON.

At authorisation, the programme reserves $120 on the subledger while the sponsor bank’s ledger stays unchanged.

At settlement you pay, and the reserve becomes a posted debit.

A rail rejection restores the available amount.

The pooled liability falls to $380.

The named customer’s allocation falls by the same amount.

Both statements are true.

They belong to different layers.

There are three records in that routine.

Your ledger says you owe $380 in the pooled deposit account.

The programme ledger says this particular customer is allocated $380.

The processor record says whether it accepted, returned, settled or reversed the instruction.

None of the three is a decorative copy of the others.

None alone answers every question.

A debit-card authorisation and an ACH credit also have different timing and reversal mechanics. Which is why your record names the rail and the state transition, rather than filing every outgoing movement under the comforting heading payment.

This is where embedded-finance rhetoric becomes very interested in the journey.

The host platform does own the journey.

It chooses the screen, the prominence, the default placement and the handoff.

Distribution decisions.

They can affect customer outcomes.

They are not deposit-taking.

You and the rail execute the regulated payout.

The programme ledger records the customer allocation, subject to your reconciliation.

Where a ledger adjustment is required, demand a named bank-approved operator.

There should be no anonymous hand reaching into a customer balance because the dashboard has become awkward.

The Reconciliation Is the Product

At the stated cut-off, your sponsor compares its core deposit balance with the sum of relevant customer allocations and pending or in-transit items.

The programme compares its subledger with processor settlement files and your confirmations.

That produces a classification, not a decorative exception queue.

Timing item.

Rejected instruction.

Duplicate event.

Fee.

Manual adjustment.

Unknown transaction.

True shortfall.

Every cent requires an explanation.

A phrase that sounds fussy right up to the moment the programme has an unresolved difference.

A timing item needs settlement evidence.

A rejected instruction needs a restoration decision.

A duplicate event needs a reversal.

A fee needs a basis.

A manual adjustment needs an approver and a reason.

An unknown transaction needs an investigation.

A true shortfall needs escalation.

Calling all seven recon exceptions has the analytic value of calling all hospital admissions a touch unwell.

UK payment and e-money institutions run daily internal and external safeguarding reconciliations, with monthly reporting inside a set number of business days after month end.

Not a U.S. rule.

A useful display of the point.

Reconciliation cadence is an accountability choice, and a monthly match allows thirty days for a bad assumption to acquire friends.

Your own cut-off and cadence want naming, testing and recording.

Not inheriting from an attractive slide about real-time finance.

An unresolved break leads to investigation from primary evidence, correction entries with an approver and a reason, customer communication where available balance is affected, and escalation to you.

A freeze or risk limit reaches only as far as necessary.

The conclusion you want is replayable.

The receipt, the reserve, the bank’s liability, the customer’s allocation and the rail outcome all agree when reproduced.

Dashboard green is an aesthetic. Reconciliation is an argument with exhibits.

Accountability Has a Long Memory

The joint agencies statement applies to banks using third-party arrangements to deliver deposit products and services to end users.

Its risk categories run operational, compliance, liquidity, concentration, consumer-protection and insurance-representation.

A useful list, because it stops the programme mistaking a successful API call for successful banking.

You can assign the programme manager to collect KYC information, operate sanctions screening, receive complaints, process data, maintain the subledger, monitor transactions and review marketing.

You remain accountable for safe and compliant performance.

All of it.

So for each item, the regulated institution needs the control owner, the performance evidence, access to the relevant record, the exception path and the approval right.

A contract makes that testable for you.

It does not make a regulator lose interest.

The same divide appears on the customer-facing screen.

Your host owns its own statements and conduct.

It cannot make a financial product look like a price discount, hide a consequence in a purchase flow, or promise approval before the provider has decided.

When it changes the order of offers, alters a required disclosure, passes data that affects a decision, or creates a new channel, it has made a compliance-controlled change.

The evidence is pleasingly unromantic.

Approved copy.

Screen captures.

Decision logs.

Version identifiers.

Audit rights.

Incident notices.

Complaint routing.

Data-use limits.

Record retention.

Subcontractor approval.

Suspension rights.

Termination support.

Your requirement for visibility is not nostalgia for the branch.

The guidance says management should determine whether it has appropriate access to third-party data and information.

The processor has it describes a fact about the processor.

It does not answer your question.

For programmes using several banks, the record also identifies the bank location alongside the customer allocation and settlement state, so a programme total cannot conceal a deficit in one account.

A total that ties while one bank is short is one of finance’s more polished lies.

The Failure Test Is the Only Test That Counts

Your programme is well designed when normal activity is boring and failure is still operable by you.

Your termination plan preserves records, continues customer access, transfers or replaces service safely, identifies who communicates with end users, and keeps the records needed for insurance and disputes.

A 30-day notice can be commercially ordinary and operationally absurd, where the subledger has not been validated, replacement credentials do not exist, or a controlled account migration has never been rehearsed.

The most useful failure exercise asks facts that refuse to be answered by a responsibility matrix.

If a programme manager fails, which bank account contains the funds?

Who has the allocation file?

Who can identify the legal customer and the available balance?

Who approves a correction?

Who handles the complaint?

Who freezes a payment?

Who tells the customer?

Who supplies the records for a deposit-insurance determination?

And who may move money when everybody would very much like the answer to be Operations?

One FDIC consent order required an assessment across 12 specified areas.

Partner financial condition.

Complaints.

Transaction concerns.

Concentration.

Insurance misrepresentation.

Financial-crime controls.

With a correction plan inside a month and monthly board monitoring.

An institution-specific remedy, not a universal template.

It is nevertheless a fine illustration of a durable supervisory habit. When oversight becomes inadequate, the supervisor does not become interested in the partnership’s preferred nouns.

Your sponsor bank remains the accountable regulated institution.

The programme manager may be operationally responsible for a task. The non-bank host remains responsible for its own representations and conduct.

The customer needs the actual bank, the product, the fees, the applicable rules and the limits of deposit insurance disclosed. Not a familiar brand standing in for the legal counterparty.

Everybody gets a job.

Nobody gets an invisibility cloak.

The Ladder, Because the Screen Has Been Persuasive Again

Customer interface?

Go to the distributor.

Regulated account?

That is yours.

End-customer subledger?

Go to the programme ledger, subject to reconciliation.

Funds location?

Go to your bank account.

Compliance decision?

Go to the accountable regulated institution.

Payout execution?

Go to you and the rail.

Ledger adjustment?

Demand an operator you have named and approved.

A non-bank may operate the experience; it may not operate away the bank’s accountability.