To the customer, the journey and regulated service may appear as one product. Several organisations perform the underlying work. The fintech typically shapes the interface, acquisition flow and product experience, while the sponsor bank provides the regulated banking relationship. Behind them, middleware, processors and specialist providers connect instructions and account states to payment rails, compliance decisions and financial records.

Responsibility for the bank’s legal and prudential obligations stays with the sponsor bank. Fintechs and technology providers carry their own contractual, operational and applicable legal responsibilities. To make this allocation operational, the programme translates it into system permissions and data access, then connects control execution to oversight evidence and intervention rights.

Governability depends on what the bank can observe and do. It can trace each material decision to the party that made it and intervene directly when a customer, account, payment or control requires action.

Beginning with product design and approval, the programme boundary extends through onboarding and account creation into payment initiation, screening, authorisation and posting. Reconciliation, servicing, complaints, account closure and exit complete the operating perimeter.

A dependency belongs inside this boundary when it can:

• approve or reject a customer;
• create, restrict or close an account;
• initiate, release, hold or reverse a transaction;
• create or alter a financial record;
• affect customer access to funds;
• supply evidence used for a regulated decision;
• interrupt the bank’s ability to operate or reconstruct the service.

Embedded finance describes where a financial capability appears within a customer journey. BaaS defines the institutional and operational arrangement that delivers the regulated capability. Core banking systems, processors, ledger platforms and compliance services provide components within that arrangement.

Within this boundary, every material action, record and dependency has an identifiable owner. During disruption, recovery or programme transfer, the same perimeter determines which functions continue, which records move and who can act on them.

The operating sequence begins before the first customer enters the fintech interface. The sponsor bank approves the product structure, intended customers, jurisdictions, account types, transaction capabilities, payment rails, limits, fees, disclosures, control policies and service-provider chain.

The approved perimeter must become a controlled configuration across the bank, fintech, middleware and processors. Programme identifiers, product versions, control-rule versions and effective dates allow each participant to determine which terms governed a customer or transaction at a specific time.

Material changes return through programme governance. A new customer segment, geography, funding method, payment rail, AI-driven function or service provider can alter the risk profile and operating responsibilities. Change approval must reach the production configuration before the feature becomes available.

The fintech captures identity information, business information where applicable, disclosures, consents and product selections. Middleware may route these inputs to verification, screening, fraud and risk-classification services. The sponsor bank’s approved policy determines the conditions for acceptance, review, restriction or rejection.

The decision record should retain:

• the submitted customer data;
• the services and data sources consulted;
• the rules and thresholds applied;
• the resulting decision and reason;
• any manual review or override;
• the approving actor and timestamp;
• conditions placed on the customer or account.

Customer approval and account creation are separate transitions. Middleware acceptance marks an intermediate state. Account availability begins after the authoritative bank or processor record creates the account, returns its identifiers and maps them to the customer and programme.

This distinction prevents the interface from presenting an open or usable account while the regulated record remains pending, rejected or restricted.

A transaction begins when the programme captures an instruction. The system assigns a persistent identifier and records the initiating customer, channel, account, amount, currency, intended counterparty and time.

Before external submission, the control layer authenticates the actor and evaluates account status, permissions, limits, screening results and fraud signals. An authorised instruction then moves through the relevant processor, bank and payment system.

Each participant may return its own status. The middleware must map these messages into defined programme states and retain the original source response. A customer-facing “successful” status must correspond to a specific internal event such as authorisation, rail acceptance, posting or settlement.

The order of posting and external settlement varies by rail and product. The architecture should therefore record authorisation, submission, acceptance, settlement, return and ledger posting as separate events. The complete state sequence belongs to the broader payment lifecycle.

Reconciliation closes the operating loop. It tests whether bank, processor, platform, rail and customer-facing records describe the same completed activity. A difference creates an owned exception with an amount, affected records, cause, ageing status and resolution path.

Servicing continues after the original transaction. Returns, disputes, chargebacks, fraud restrictions, fee corrections, account adjustments and customer complaints may change the financial or operational position. Payment operations must preserve the relationship between the original event, subsequent action, decision owner and resulting record.

Account closure requires a controlled sequence:

1. restrict new activity;
2. identify pending transactions and unresolved exceptions;
3. settle or return the remaining customer position;
4. align platform, processor and bank records;
5. close associated payment instruments and access rights;
6. issue required customer communications;
7. retain the account, transaction and decision evidence.

Programme termination applies the same logic across the full customer population. The bank and its partners must preserve service continuity, customer-fund access and record integrity while activity is closed or transferred.

The customer-facing balance represents the amount that the programme currently presents as available, pending, restricted or posted. It may come from a platform subledger, processor balance service or cached event stream. Its reliability depends on the source event, update time and rules used to convert operational states into a displayed amount.

The bank record shows the deposit or account position carried within the bank’s own books and systems. A processor record may establish how a payment instruction moved. A settlement record confirms an external payment event. The general ledger records the bank’s accounting position. Reconciliation evidence establishes whether these records align.

A programme should retain the source, timestamp and state behind every displayed balance. When records update on different operating clocks, the interface needs a defined rule for pending items, delayed events and corrected positions.

A BaaS programme may establish individual accounts for each customer or place funds into a pooled account supported by a separate record of customer interests.

In an omnibus arrangement, the bank account may show one named accountholder and one aggregate balance. A platform, processor or other recordkeeper then allocates that balance among underlying customers. The architecture must connect every customer interest to the pooled bank position and preserve the total across funding, payments, fees, holds, returns and adjustments.

An account titled “for the benefit of” or FBO indicates an agency or custodial relationship. In the United States, eligibility for pass-through deposit insurance depends on the actual ownership of the funds, disclosure of the custodial relationship in the insured bank’s records, and records that identify each principal and ownership interest. The FDIC’s pass-through coverage guidance also explains that pass-through treatment uses the underlying owner’s applicable insurance category and aggregation position.

The FBO designation therefore supplies one part of the record structure. The programme also needs genuine ownership arrangements and complete beneficial-owner records. A multi-tier structure must preserve each agency level through the bank, programme manager, middleware and any subsequent recordkeeper.

Sweep arrangements add movement between accounts or institutions. Their records should identify the source account, destination, beneficial owner, amount, initiation time, settlement timeframe and current state. During the interval between instruction and completed sweep, the programme must establish which institution carries the position and which balance the customer can use.

Authority follows the question and the state being examined.

The authoritative record may change as a transaction progresses. A processor acknowledgement can establish submission while the bank ledger establishes posting and the settlement record establishes completion on the external rail.

Ledger architecture defines how postings, balances and sources of financial authority are organised. Reconciliation architecture establishes how the programme proves agreement across those sources and resolves breaks.

The bank needs access to records at a level that supports oversight, customer servicing, financial reconstruction and intervention. Access should continue through provider disruption, contractual termination, insolvency and programme transfer.

Operational portability requires:

• customer and beneficial-owner identifiers;
• account and programme mappings;
• opening, pending, available and restricted balances;
• complete transaction and adjustment history;
• event timestamps and processing cut-offs;
• links between bank, platform, processor and rail identifiers;
• control decisions, rule versions and overrides;
• reconciliation status and unresolved breaks;
• data definitions, schemas and version history;
• contracts, licences and support rights required to operate the records;
• tested procedures for extraction, validation and loading into an alternative system.

The transfer dataset must reconcile to the bank position at an agreed cut-off. It should preserve transaction order, ownership interests, pending items and the evidence needed to explain each resulting balance.

The FDIC’s June 2026 resolution-submissions proposal applies to covered insured depository institutions and remains a proposed rule. It nevertheless provides a current architecture signal. The proposal asks covered institutions to identify omnibus, sweep and pass-through accounts, the systems that maintain them, relevant contracts, reporting delays, third-party digital products and the systems on which customer records are retained.

The proposal also connects digital-service continuity with transfer, replication and support through alternative systems. This extends the record question from day-to-day accuracy to resolution portability: whether another authorised operator can reconstruct the programme, preserve customer positions and continue or close the service from the available records.

The failure map should identify the affected products, accounts, states, records and control functions. It should also name the party that can restrict further activity, establish a cut-off and coordinate recovery.

Systems can remain available while their records diverge. A platform may display a balance that excludes a late return. A processor may record a completed payment while the bank posting remains absent. A pooled bank account may balance in aggregate while customer allocations contain errors.

Common divergence patterns include:

• a missing event between systems;
• a duplicated instruction or retry;
• an event processed out of sequence;
• settlement without the expected posting;
• posting without external confirmation;
• an adjustment linked to the wrong account or transaction;
• a customer allocation that differs from the pooled position;
• a stale restriction or release state;
• a control decision that lacks supporting evidence.

Customer ownership, account access and interface availability describe separate conditions. A customer may retain an interest in funds while the programme lacks a reliable mechanism to calculate the amount, display it or permit withdrawal. Recovery must therefore address both the financial position and the channel through which the customer can exercise account rights.

When confidence in one record falls, the programme needs a controlled method for selecting evidence from the bank, platform, processor and payment system. Broad restrictions may protect the programme during reconstruction. The restriction decision, affected population, financial basis and release criteria should remain documented.

The Synapse collapse case study examines a named failure across sponsor banks, middleware, ledgers, reconciliation and customer-fund access. The permanent BaaS page owns the system principles; the Insights article owns the event chronology and institution-specific evidence.

Recovery begins by stopping uncontrolled state changes and establishing a common cut-off. Each participant must preserve its records as of that point and continue capturing any later events in a segregated queue.

A reconstruction sequence can then:

1. identify all programme accounts, customers and beneficial owners;
2. collect bank, platform, processor, rail and control records;
3. map shared identifiers across the datasets;
4. establish the bank-level account and pooled positions;
5. rebuild individual customer allocations;
6. classify pending, settled, returned and disputed transactions;
7. reconcile financial totals and event counts;
8. isolate remaining exceptions with named owners;
9. restore, transfer or close the service from the verified position;
10. communicate the resulting status to customers.

The recovery dataset needs sufficient detail to reproduce financial states and explain them. It should include configuration versions, rule logic, event ordering, pending items, access restrictions, manual adjustments and unresolved cases.

A viable exit plan also secures the operating rights required to use those records. Contracts should address data delivery, format, frequency, intellectual-property licences, support personnel, credentials, encryption keys, cloud resources and continued service during transition.

The US banking agencies’ joint statement on third-party deposit arrangements identifies contingency plans and contractual provisions that facilitate the transfer of accounts, data or activities following disruption, bankruptcy or failure of a third party.

Testing should include extraction from the production provider and loading into an alternative environment. The test should reconcile customer positions to bank totals, reproduce open transaction states and demonstrate that authorised operators can perform essential actions.

Resolution portability measures whether an authorised party can reconstruct and operate the programme using records, rights and resources available outside the failed component.

The FDIC’s June 2026 resolution-submissions proposal remains prospective and applies to covered insured depository institutions. It asks covered banks to identify the systems that retain customer records for digital products and describes transfer, replication or alternative-system support as relevant to resolution execution.

This provides a wider architecture principle for BaaS: continuity depends on the ability to carry authoritative customer positions, transaction states, controls and operating rights across an institutional or technology boundary.