In a traditional bank, a payment card is a physical artifact tied to a pre-allocated ledger state.
You apply for a card. The bank’s underwriting system reviews your credit, allocates a $5,000 credit limit on your account row, orders a piece of plastic from a printing factory, and mails it to you. When you swipe it, the merchant terminal asks the bank, “Does this account have $5,000 available?” The bank checks its core and says yes.
Even when we digitized this process—putting the card into Apple Pay or Google Wallet—the underlying architecture remained identical. The phone was just tokenizing an already-existing, pre-funded physical card account.
Banking-as-a-Service (BaaS) completely broke this model. It replaced the pre-funded physical card with a concept called Just-In-Time (JIT) Funding.
In the BaaS architecture, a card is no longer a physical object, and it is no longer tied to a pre-allocated balance. A card becomes a stateless, programmable API endpoint that only springs to life at the exact millisecond a transaction occurs.
1. The Stateless Card Concept
To understand JIT funding, you have to abandon the idea that a card “holds” money.
When a neo-bank user clicks “Generate Virtual Card” in the app to make a one-time online purchase, no money is moved. No balance is allocated. The card processor (like Marqeta or Galileo) simply generates a random, valid 16-digit number that conforms to the Visa or Mastercard network rules, and ties it to the user’s User ID.
The card credential itself does not maintain an independent monetary balance. The available spending power is determined dynamically by the underlying account ledger and authorization rules. It cannot be used to buy a cup of coffee because the underlying ledger state has not yet been mapped to the card network.
The architectural pivot occurs in the milliseconds between the swipe and the network approval.
2. The Authorization Flow: The JIT Trigger
Let’s say the user takes that virtual card and tries to buy a $50 item at an online store.
Step 1: The Network Routing The online store sends a standard authorization request to its Merchant Acquirer. The Acquirer routes it to the Visa or Mastercard Network, which identifies the Issuer Processor responsible for the credential.
Step 2: The Processor Check The Issuer Processor receives the request: “User 8472 wants to spend $50.” In a legacy system, the processor would just ask the sponsor bank if User 8472 has a $50 pre-allocated limit.
In a JIT system, the processor behaves differently. It looks at the user’s shadow ledger (or queries the sponsor bank’s FBO pool via API) and verifies the user actually has $50 in their underlying checking balance.
Step 3: The Just-In-Time Funding Instruction Once the processor confirms the $50 exists in the user’s neo-bank account, it executes the JIT maneuver. The processor triggers a real-time funding instruction through the program’s payment infrastructure. Depending on the specific architectural setup, this may involve an API call to the sponsor bank’s core, a transfer within the processor’s internal ledger, or a draw against prefunded settlement accounts.
Step 4: The Ledger Allocation The necessary infrastructure executes a double-entry write—debiting the user’s underlying pooled liability and crediting a transient card settlement ledger. The funds are now mapped to the specific card transaction. This takes milliseconds.
Step 5: The Approval The processor receives confirmation that the funds are secured in the settlement layer. It tells the Card Network: “Approved.”
From the Card Network’s perspective, nothing unusual happened. They just saw a standard authorization approval against a funded account. They have no idea that the funds weren’t mapped to the card credential a second before the swipe. The money was materialized into the settlement layer just-in-time to satisfy the network’s rigid authorization rules.
3. The Authorization State Machine
To view this through the lens of database architecture we’ve established in this series, a card transaction is a temporary execution event against a permanent state. The transaction flows through a strict state machine:
CARD CREDENTIAL CREATED
│
▼
AUTHORIZATION REQUEST
│
▼
PROGRAMMABLE RULE ENGINE CHECK
│
▼
FUNDS RESERVED / ALLOCATED
│
▼
TRANSACTION APPROVED
│
▼
CLEARING
│
▼
FINAL SETTLEMENTThe programmable logic of the BaaS card operates entirely within the “Rule Engine Check” phase. Because the processor controls the logic gate before the “Funds Reserved” state is triggered, the neo-bank can program arbitrary rules into the card network:
- Single-Use Cards: The processor can be instructed to approve exactly one transaction for this 16-digit number, and instantly destroy the credential state afterward. This eliminates fraud risk on sketchy websites.
- Merchant Locking: A delivery company can issue a digital card to a driver, but program the rule engine to only approve the state change if the merchant category code (MCC) is specifically “Gas Stations.” If the driver tries to buy electronics, the processor blocks the transition.
- Dynamic Limits: The neo-bank can adjust spending power dynamically. If a user’s underlying checking account drops below $100, the rule engine can be programmed to reject all authorization requests for non-essential categories, effectively turning the card off for certain merchant types in real-time.
4. The Settlement Phase
The state machine does not end at approval.
The authorization stage has already reserved or allocated the necessary funds. Later, during the clearing phase, the merchant’s Acquirer and the Issuer Processor exchange transaction details. Finally, during settlement, the movement of funds is finalized through the card network’s settlement process.
Because the funds were already isolated into a transient settlement ledger during the JIT authorization, they are ready to be swept into the net settlement bathtubs (CHIPS/Fedwire) to clear out to the merchant’s bank at the end of the day.
The Architecture Revealed
Traditional card networks were built for a world of physical plastic and pre-approved ledger limits. They assume a card is a static repository of funds or credit.
JIT funding is an architectural bridge that connects modern, programmable cloud environments with rigid, legacy card networks. By intercepting the authorization request and materializing the funds milliseconds before the network demands them, BaaS processors turned the payment card from a static financial product into a piece of executable, real-time software.
There is no plastic. There is no pre-allocated balance. There is only a 16-digit API endpoint waiting for a database trigger.
USER CLICKS "BUY"
│
▼
MERCHANT CHECKOUT
│
▼
MERCHANT ACQUIRER
│
▼
VISA / MASTERCARD NETWORK
│
▼
ISSUER PROCESSOR
│
┌────────────┴────────────┐
│ │
▼ ▼
CHECK SHADOW LEDGER PROGRAMMABLE RULES
(Does user have $50?) (Is merchant allowed?)
│ │
└────────────┬────────────┘
│ (If Yes)
▼
JIT FUNDING INSTRUCTION
│
▼
SPONSOR BANK / PROCESSOR LEDGER
│
▼
ALLOCATE TO TRANSIENT SETTLEMENT
│
▼
PROCESSOR TELLS NETWORK: "APPROVED"