Embedded finance runs on banks. You need to decide what infrastructure sits between your product and the banking system.

This matters more than most teams realize during evaluation. The architecture you build on determines what data you can access, how payments behave, what you can debug when something breaks, and whether you'll need to rebuild systems as you scale.

It also determines what happens when your requirements change (and they will) 

• Can you add a second bank partner without a separate integration? 
• Can you support a new payment rail like RTP without waiting for your provider's roadmap? 
• Can you control operational details like ACH clearing windows or check deposit workflows, or are those locked inside a system you can't reach? 
• Is your relationship with the bank actually yours, or mediated through your provider?

Most embedded finance infrastructure wasn't built to answer these questions well, because most of it runs on top of legacy bank infrastructure that was never designed to be programmable. That rigidity is invisible during evaluation. It shows up six or twelve months later, when the product needs to evolve and the infrastructure can't.

This guide covers six architectural choices that define how Unit works: our native ledger, direct Federal Reserve connectivity, network-level data exposure, account primitives, multi-bank partnerships, and configurable control boundaries: what each one does, why we built it that way, and how to evaluate whether it fits what you're building.

Critical architectural choices we made

1. Native ledger

When you create an account through the API, that account exists in a native ledger. Balances update in real time. Transactions are recorded as they happen. Reconciliation is continuous, not batched overnight.

Accounts on Unit are deposit accounts (DDAs) held at partner banks and FDIC-insurance eligible under the bank's charter. This native ledger serves as the operational system of record for all account and transaction activities.

Every state transition is recorded on the ledger with timestamps tied to actual network events. You can see exactly where a payment is relative to cutoff windows, settlement, and returns. The same ledger data is accessible through a Dashboard, so your operations team and bank partners can view account activity, transaction history, and payment status without requiring engineering support or separate reporting tools.

curl -X POST 'https://api.s.unit.sh/accounts'
-H 'Content-Type: application/vnd.api+json'
-H 'Authorization: Bearer ${TOKEN}'
--data-raw '{
  "data": {
    "type": "depositAccount",
    "attributes": {
      "depositProduct": "checking",
      "tags": {
        "purpose": "checking"
      },
      "idempotencyKey": "3a1a33be-4e12-4603-9ed0-820922389fb8"
    },
    "relationships": {
      "customer": {
        "data": {
          "type": "customer",
          "id": "45555"
        }
      }
    }
  }
}
// The account is immediately active. 
// It can receive funds, send payments, and issue cards, without waiting for downstream systems to catch up.

‍‍

2. Direct connection to payment networks

Unit is a registered service provider with the Federal Reserve. Payments flow from our infrastructure directly to Federal Reserve systems, on behalf of our partner banks.

Under the hood, we operate dedicated infrastructure in secure Equinix data centers where we run the Federal Reserve's required systems for Fedwire, FedACH, and checks. We've built and maintain our own services that speak the Fed's protocols directly, and we're regularly examined to stay certified.

When you originate a payment through the API, it is submitted directly to the Federal Reserve network on behalf of partner banks. There is no intermediary processing layer in the middle.

This architecture is what allows the infrastructure to expose true network-level detail and status. IMADs (Input Message Accountability Data), precise settlement timestamps, raw return codes, and real-time updates aren't approximations or delayed relays - they come from the Federal Reserve messages we receive and process ourselves.

This matters for three reasons:

1. Processing windows are explicit. ACH doesn’t run continuously. It moves in defined Federal Reserve windows throughout the day. Because the infrastructure submits payments directly to the network, we align submission to those windows. You know exactly when a payment will be processed, not just when your API call returned successfully.‍
2. Network acknowledgments are observable. When the Fed acknowledges receipt of a payment, that event is captured and exposed. You're not inferring status from the absence of errors, it’s based on actual network responses.
3. ‍Settlement timing is deterministic. You know when funds will settle because the system tracks the real network lifecycle end to end. Settlement timing reflects what’s happening at the Federal Reserve, not an approximation layered on top of a bank’s legacy system.

3. Network-level data

Most platforms abstract payment rails to simplify their APIs. We take the opposite approach: we expose the data that payment networks actually produce.

For wire transfers, this includes:

• IMAD (Input Message Accountability Data) and OMAD (Output Message Accountability Data) - the unique identifiers assigned by Fedwire
• Network timestamps for each lifecycle event
• Raw status codes when something fails

For ACH, this includes:

• Trace numbers
• Return reason codes (R01, R02, etc.) as received from the network
• Actual settlement dates, not estimated ones

{
  "type": "wireTransaction",
  "id": "9547",
  "attributes": {
    "createdAt": "2020-07-05T15:49:36.864Z",
    "direction": "Credit",
    "amount": 1000,
    "balance": 12000,
    "summary": "Wire to Jane Smith",
    "imadOmad": {
      "imad": "123456",
      "omad": "654321"
    },
    "counterparty": {
      "name": "Jane Smith",
      "routingNumber": "812345678",
      "accountNumber": "10039",
      "accountType": "Checking"
    }
  },
  "relationships": {
    "account": {
      "data": {
        "type": "depositAccount",
        "id": "10035"
      }
    },
    "customer": {
      "data": {
        "type": "customer",
        "id": "5"
      }
    }
  }
}
// When a payment fails or behaves unexpectedly, you don't need to open a support ticket to find out what happened. 
// The data is already in the API response and webhook payloads.

4. Multiple account primitives

The ledger supports deposit accounts, wallet accounts, and credit accounts as distinct, first-class account types, each with its own data model and behavior, all maintained on the same ledger. All accounts are shown in a single dashboard.

All account types:

• Are created under a customer
• Have a balance and transactions under them
• Have an individual routing number and account number
• Can send and receive payments
• Can contain cards that use their balances
• Have associated terms and limits based on your policies

Deposit accounts are FDIC-insurance eligible deposit accounts held at partner banks. Each carries its own routing and account number and can send and receive payments, issue cards, and accrue interest. These are real bank accounts, not balance abstractions.

Wallet accounts are balances under your customers that aren’t deposit accounts, but may offer a large subset of the functionality in deposit accounts. They represent a different relationship where the user holds a balance with you, not the bank. They are more flexible than bank accounts in some areas, and more restrictive in others. Wallets are typically used in money movement use cases, like accounts receivable or accounts payable. In other systems, wallets are offered or described as “[sub]ledgered FBO accounts” or “financial accounts”.

Credit accounts represent money loaned to an end user rather than money held on their behalf. Each credit account maintains a defined credit limit, the customer's current balance, pending authorizations (holds), and an available credit limit that updates in real time. This makes it possible to model charge cards, lines of credit, and other lending workflows directly on the ledger, with deterministic state.

5. Direct, multi-bank partnerships‍

Your relationship with the bank is yours, not mediated through Unit. You choose your bank partner. You negotiate terms directly. Your teams work together on compliance, operations, and program design. We provide the infrastructure that makes the partnership work; we don't sit between you and the bank.

This is an architectural choice, not just a business relationship. The API and Dashboard work consistently regardless of which bank partner is behind a given account. That means:

• You can start with one bank and add others as your program scales or your needs change
• Different products or customer segments can run on different bank partners through the same integration
• If you need to move accounts from one bank to another, the migration tooling handles it without disrupting end users

This matters because regulatory shifts, management changes, consent orders, strategic pivots… these happen, and when they do, single-bank dependency becomes an existential risk. Multi-bank support isn't a feature you'll need someday. It's insurance you want from day one.

6. Control all program elements - immediately or over time

The Roles & Responsibilities settings let you take control of specific elements, immediately or over time. You can use off-the-shelf capabilities for KYC/KYB, card processing, fraud prevention, and compliance monitoring. Or you can bring your own stack where you have specialized requirements or existing vendor relationships. These boundaries are configurable and can change over time, in coordination with your bank partner.

This means you're not locked into a single operating model. Teams often start with Unit handling most operational complexity, with oversight and from partner banks, then selectively take on more control as their program matures and their internal capabilities grow. The platform supports both approaches (and the transition between them), without requiring migration or reintegration.

This runs in production, at scale

• Scale: Processing 5+ billion API calls and $50+ billion in transactions annually.
• Uptime: Maintains 99.99% uptime, reflecting consistently high reliability.
• Secure & compliant: SOC 2 Type 2 and PCI DSS.
• Developer experience: A single API, a single dashboard, and comprehensive documentation. Your engineering team, your operations team, and your bank partner all work from the same system. 

Next Steps

If you're evaluating an embedded finance platform:

Explore the API documentation. The API reference shows exactly what data is available for each resource type. Look at the payment objects as the fields exposed there reflect the network-level visibility we've described.

Sign up for sandbox access. The best way to understand the infrastructure is to use it. Create accounts, submit payments, and see what data comes back.

Talk to the team. If you have specific architectural questions about payment flows or bank partner options, please reach out.

‍

^{* Unit is a financial technology company and is not a bank. Banking products and services are provided by Unit’s partner bank(s), Members FDIC.}