Embedded finance that stays under your controls.

Banking-as-a-service (BaaS) is a model in which a chartered bank provides accounts, cards and payments to the customers of a non-bank partner, inside that partner’s app and brand. The bank remains the regulated institution holding the deposits; the partner owns the customer experience. Fabric is the Nucleus BankOS module a bank uses to run those programs.

Fabric is the banking-as-a-service module of Nucleus BankOS. It gives each partner an isolated program with governed APIs for onboarding, accounts, cards and payments, and keeps every end-user balance on the bank’s ledger.

A partner risk and compliance framework, a ledger that shows each end user’s balance, controlled onboarding, card and payment operations, and a way to monitor partner activity. Fabric supplies the systems: program isolation, the sub-ledger, the onboarding flow, limits, monitoring and the audit trail. The bank supplies the policy, the people and the partner agreements.

Partners submit applicant data and documents, but no API scope lets them set a verification result. Identity verification, diligence and the decision are made by the platform or the bank’s designated vendors, and borderline cases route to bank staff.

An FBO (for-benefit-of) account is a pooled account at the bank held on behalf of many end users; a sub-ledger is the record of what each of those end users owns. In many BaaS programs that record lives with a middleware vendor. In Fabric the sub-ledger sits on the bank’s core and posts to its general ledger.

Over BroadStreet, adapfin’s private connectivity layer, through the bank’s own network; there is no public API host. The bank issues each partner a program-scoped key with only the scopes it needs, and the partner builds in a sandbox before production keys are issued.

The recurring cost is mostly oversight: compliance staff, partner due diligence, reconciliation and the middleware between partner and core. Fabric removes the separate middleware ledger and puts onboarding, limits, monitoring and audit on the core, so the ongoing work is configuring programs and supervising partners. Pricing is quoted per bank; a business case models it against your current setup.

Yes. Nucleus BankOS sets the system of record per data class, so deposits can sit on Nucleus while loans stay on the incumbent core, or both can hold a record with a daily tie-out. Fabric programs follow those settings.

Yes, with Foundry. Embedded cards, pay-later and lines of credit are underwritten on Foundry under the bank’s credit policy and booked to the same ledger as the partner’s deposits.

On every write. The bank sets per-transaction ceilings, daily and velocity caps, and an optional auto-release ceiling above which money movement waits for human approval. Raising a limit is a logged administrative action.

Every API call, money movement, decision and configuration change is written to an append-only audit trail, and partners must log their own access and error events back to it. The bank can follow any action from the partner’s side to its effect on the ledger.

That depends on how accounts are titled and whether the records identify each owner and balance, so the bank and its counsel make the determination. Fabric keeps those per-end-user records on the bank’s core and tracks coverage per partner.

Yes. Fabric is a module of Nucleus BankOS; embedded credit also requires Foundry.