Your Banking Infrastructure (Core Surface)

Behind every program sit real bank accounts on Lead’s core: the FBO that pools your customers’ deposits, and the operating, settlement, revenue, and reserve accounts your program runs on. Lead opens and manages these during onboarding. You do not create them; you read them. Today you read them through the Daily Balance and Daily Activity reports, online banking, and the account_id values on payment objects and Account Numbers. As the core APIs roll out, you can also read them directly over the API. This is the core surface described on the Object Model page. Lead is the actor here, which is why the data comes from Lead rather than being reported by you. That is the mirror image of Customers & Accounts, where you are the ledger of record.

The Core Account, Core Balance, and Core Transaction APIs are in beta. Beta APIs may change without a version increment. Changes are announced in advance and your Technical Account Manager works with you on them.

Core Surface

The foundational accounts you use to operate your program. Lead opens them for you during onboarding and manages their lifecycle; you read them through the online banking UI, the daily reports, and the core APIs, but you don’t open or close them yourself. The core APIs return each one with a type.

FBOs. Pooled “For Benefit Of” accounts that hold your customers’ funds in aggregate. In the core APIs an FBO is attributed when its funds are attributed to customers through user balances, and direct when it is not.
Operating accounts. Day-to-day DDAs for operating, revenue, reserve, settlement, network settlement, and so on. In the core APIs these are direct.
Shadow accounts. Secondary sweep or placement positions such as IntraFi ICS. In the core APIs these are shadow. Read only; nothing transacts against them and account numbers never attach.

Two ways to read the core surface

Today (account_id)
Core APIs (/v2)

On the objects you use today, an account and its balance are one thing. A core account is one of your FBOs, operating DDAs, or shadow accounts, identified by account_<id>, and it carries the balance.

Identifier: account_<id>, as it appears on account numbers and payment objects.
Balance: read from the Daily Balance report or online banking.
Transactions: read from the Daily Activity report or online banking.
Held by: your Lead or partner entity. Opened and managed by Lead.

Entity (Lead or partner)
└── Account                   (account + balance combined, account_<id>)
    └── Account Number        (routable payment address)

The core APIs split the same account into three read-only resources. Every ID carries its object type as a prefix.

Core Account (core_account_*). The bank account: name, type, status, and the entities that hold it. See Core Accounts.
Core Balance (core_balance_*). The balance position within the account: posted, holds, sweeps, overdraft, interest, and a derived spendable figure. One per account today. See Core Balances.
Core Transaction (core_transaction_*). A ledger entry that changed a core balance, with a type naming the rail or mechanism that created it. See Core Transactions.

Entity (Lead or partner)
└── Core Account              (core_account_*)
    └── Core Balance          (core_balance_*)
        ├── Core Transaction  (core_transaction_*)
        └── Account Number    (routable payment address, where permitted)

All three are on /v2/ and each has a single read scope: core_account/read, core_balance/read, core_transaction/read.

How the two models relate

The accounts are the same bank accounts. What changes is how you refer to them. Core objects carry typed IDs: core_account_* and core_balance_*. The account_id on your v1 account numbers and payment objects is a different identifier. The core endpoints do not accept it, and there is no lookup by legacy account_id. Read the balance with GET /v2/core_balances/{core_balance_id}; its core_account_id field gives you the parent core account. account_id keeps working on v1 and is not removed during the migration window. What does not change:

v1 account numbers and payment objects keep working through the migration window. Nothing is removed from them.
Typed IDs are opaque strings. Store them as returned. Do not parse them or derive meaning from the prefix beyond object type.
The Daily Balance and Daily Activity reports are unchanged. The core APIs return the same figures and the same entries on demand.

Account Number

The routing number and account number pair that lets money reach an account on Lead’s payment rails. A single core account can have many — for example, one for each end customer whose funds are pooled in an FBO. Account Numbers hang off core accounts. Even when you assign one to an individual customer, it attaches to the core account — the customer is carried on the account number’s entity_id — so an inbound payment lands on the core account first and is attributed to the customer from there.

Today: An Account Number points to a core Account (via account_id).
Core APIs: Under the core APIs the same account number attaches to the core balance. See The Core Account Object.
Lifecycle: Unassigned → active ↔ inactive → canceled. canceled is terminal; Account Numbers are never reused. See Account Number Statuses.
Controls: Per-rail allow/block rules for incoming and outgoing payments are set at the Account Number level. See Controls.

All of Lead’s money-movement APIs (ACH, wires, instant payments, and internal transfers) are indexed off the account number. You originate a payment by referencing an account_number_id, and Lead resolves the account it settles against.

Transaction (core)

Debits and credits on a core account are generated by Lead — you don’t report them. They appear in the Daily Activity Report, the online banking UI, and the core transaction API.

Lead manages, you read

You cannot create, update, activate, deactivate, or close any core object. Lead manages every state transition.
Core objects do not emit webhooks today. Poll the list endpoints instead. Payment objects keep their own webhooks.
You cannot reverse a core transaction. Corrections are new, offsetting transactions.

Banking Infrastructure

Lending & Receivables

Payment Rails

Customers & Accounts

Network Settlement

Core Surface

Two ways to read the core surface

How the two models relate

Account Number

Transaction (core)

Lead manages, you read

In This Section

​Core Surface

​Two ways to read the core surface

​How the two models relate

​Account Number

​Transaction (core)

​Lead manages, you read

​In This Section

Core Surface

Two ways to read the core surface

How the two models relate

Account Number

Transaction (core)

Lead manages, you read

In This Section