TL;DR: Yield-in-transit means earning yield on stablecoin float during the settlement window between when funds are received and when they are disbursed. For payment processors handling USDC or USDT, this window typically ranges from 2 hours to 3 days. The technical architecture is straightforward: a yield API deposits float to DeFi lending protocols on arrival and withdraws on settlement, with the payment processor retaining signing authority throughout. RebelFi provides this architecture as a non-custodial service, targeting 4-7% APY on standard yield and 7-11% on managed yield.
Key Facts:
Payment processor settlement window: 2 hours to 3 days depending on rails and counterparties
4-7% APY via flexible yield (Aave, Morpho, Kamino, Compound)
Yield deposit occurs at float arrival; withdrawal occurs at settlement trigger
Non-custodial: payment processor signs all deposit and withdrawal transactions
Aave: $1T+ cumulative lending volume, zero lender principal losses
Kamino on Solana: sub-second transaction finality, sub-cent gas fees
Morpho: $4B+ TVL, isolated markets prevent cross-market risk
Yield-in-Transit for Payment Processor Float: Technical Architecture
Settlement float is one of the largest idle assets in fintech. Payment processors hold it every day — captured funds sitting between receipt and payout, earning nothing. Yield-in-transit is the infrastructure layer that puts that float to work during the hold window without touching settlement mechanics, compliance posture, or the merchant's payout experience.
How does tl;dr work?
Yield-in-transit turns the T+1 to T+3 settlement lag into a revenue source. Payment processors holding $10M in daily float can generate $150K-$400K annually by deploying that float into DeFi lending protocols between capture and payout. The architecture requires three components: a sweep engine that moves fiat into USDC during settlement windows, a yield router that allocates to protocols like Aave or Morpho based on rate and liquidity, and a redemption layer that converts back to fiat before payout deadlines. This post covers the full technical stack, buffer sizing, risk parameters, and the reconciliation system that keeps your finance team happy.
This post is a technical deep dive. It covers the full capture-to-payout pipeline, how to size liquidity buffers, how to select yield vaults for PSP float specifically, and how to design automated sweep rules that handle real settlement patterns. For broader context on how this fits into the overall stablecoin operations stack for PSPs, see [Stablecoin Operations for Payment Processors](/blog/stablecoin-operations-payment-processors).
What Does Yield-in-Transit Actually Mean for a Payment Processor?
The term [money-in-motion](/blog/money-in-motion-vs-money-at-rest) describes capital that is owned, held, and controlled — but temporarily immobile because it is mid-transit between sender and recipient. Settlement float is the canonical example: the processor has the funds, the merchant has not yet been paid, and the hold window is a fixed structural feature of the settlement cycle. It is not inefficiency. It is the architecture.
Yield-in-transit is the operational pattern of deploying that float into yield-generating venues during the hold window, then withdrawing it in time for the payout batch to run without delay. Done correctly, the yield mechanism is invisible to the merchant. Settlement executes on its normal schedule. The processor captures the yield that previously evaporated into the opportunity cost column of someone's spreadsheet.
The difference from simple treasury management is precision. Yield-in-transit is not "put our excess cash somewhere safe." It is continuous, rule-based deployment against a settlement liability with a known maturity, managed at the individual float-pool level, with withdrawal latency tighter than the payout SLA.
What is The yield-in-transit pipeline: four stages?
``` ┌─────────────────────────────────────────────────────────────────────┐ │ YIELD-IN-TRANSIT PIPELINE │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────────┐ ┌──────────┐ │ │ │ CAPTURE │───▶│ ESCROW │───▶│ YIELD VAULT │───▶│ PAYOUT │ │ │ │ │ │ │ │ │ │ │ │ │ │ KYT │ │ Ring- │ │ Tokenized │ │ Merchant │ │ │ │ screen │ │ fenced │ │ T-bills, │ │ account │ │ │ │ flagging │ │ wallet │ │ lending, │ │ settles │ │ │ │ │ │ pools │ │ issuer yield │ │ on time │ │ │ └──────────┘ └──────────┘ └──────────────┘ └──────────┘ │ │ │ │ │ │ │ │ T+0 mins T+5-30 mins Continuous T+payout │ │ Capture Screening + accrual deadline │ │ event deployment while held │ └─────────────────────────────────────────────────────────────────────┘ ```
Stage 1: Capture and KYT screening
Every inbound settlement amount triggers a Know Your Transaction (KYT) check before entering the yield pipeline. The check evaluates wallet provenance, sanctions exposure, mixer outputs, and unusual transaction patterns. Clean funds are tagged as yield-eligible. Flagged funds enter a quarantine pool with no path to yield venues until manual review clears them.
This gate is non-negotiable and must be enforced at the infrastructure level, not as a procedural policy. The architectural separation between clean float and quarantined float is the foundation of the compliance structure. It is verifiable by regulators at the wallet level — not from a policy document.
Stage 2: Escrow into ring-fenced pools
Yield-eligible float moves into ring-fenced escrow wallets segregated by float type: merchant settlement float, risk-hold float, and prefunding balances each occupy separate pools with distinct key management and authorization policies.
This separation is a compliance requirement — not an optional design choice — under MiCA Article 68, the GENIUS Act's segregation rules, and most national money transmitter license frameworks. It is also operationally essential: you cannot attribute yield correctly, model liquidity accurately, or respond to regulatory audit requests efficiently if merchant float and operational capital are commingled at the wallet level.
For a full breakdown of the architectural and regulatory basis for pool segregation, see [Ring-Fencing Stablecoin Compliance](/blog/ring-fencing-stablecoin-compliance).
Stage 3: Yield vault deployment
Verified, ring-fenced float is deployed to yield venues according to automated sweep rules defined by the PSP's treasury policy. The deployment happens without manual intervention. Rules specify which vault categories are eligible, what maximum concentration limits apply per venue, and what withdrawal latency constraints govern vault selection.
Yield accrues continuously while float is deployed. The pipeline monitors each position's accrued yield, current rate, and expected withdrawal latency against the settlement liability schedule.
Stage 4: Merchant payout
Aave has processed over $1 trillion in cumulative lending volume since its 2020 launch, with zero instances of lender principal loss. During the November 2022 CRV market stress event, a $100 million bad debt position was absorbed entirely by the Aave Safety Module, not by USDC depositors.
When a payout batch initiates, the system calculates the required withdrawal from each yield position, executes the withdrawal, and releases funds to merchant accounts. The withdrawal-to-settlement latency target is under 30 seconds for the standard case. The instant-access liquidity buffer handles edge cases where a payout is triggered before the model's predicted settlement date.
How does yield strategy comparison: sweep cadence tradeoffs work?
The frequency at which float is swept into yield venues determines how much time is spent earning and how much operational complexity the treasury team manages. Three strategies cover most PSP implementations.
Strategy | Sweep cadence | Typical yield capture | Operational overhead | Best for |
|---|---|---|---|---|
Real-time sweep | Within minutes of KYT clearance | Highest — every hour of hold time earns | Highest — continuous position monitoring | High-volume PSPs, float with predictable hold times |
Hourly batch | Top of each hour, all cleared float | High — minimal idle time between clearance and deployment | Moderate — scheduled reconciliation, hourly position updates | Mid-size PSPs balancing yield and operational complexity |
Daily batch | Once per day, typically end-of-day | Moderate — float cleared at 11 PM earns from next morning | Lowest — single daily reconciliation cycle | Smaller PSPs starting with yield-in-transit, operations-constrained teams |
Real-time sweep deploys float within minutes of KYT clearance. For a processor with $100M in average float and a 72-hour average hold, shifting from daily batch to real-time sweep captures an additional 12-23 hours of yield per unit of float — roughly 30-60 basis points of incremental annual yield depending on the venue mix. At scale, this compounds significantly.
The tradeoff is position management complexity. Real-time sweep creates a larger number of smaller positions with staggered maturity profiles. The withdrawal scheduling logic must track each position individually against its corresponding settlement deadline. This is automated — no analyst selects venues manually — but the system complexity is higher and the monitoring requirements are more demanding.
Hourly batch is the practical optimum for most mid-size PSPs. The yield gap versus real-time is small for float with multi-day hold times: a one-hour delay in deployment costs less than 50 basis points annually. The operational overhead drops substantially relative to real-time sweep, and reconciliation cycles are predictable.
Daily batch is the correct starting point for processors without prior stablecoin treasury operations experience. It establishes the core pipeline — KYT, ring-fencing, vault deployment, withdrawal, settlement — in the most operationally legible configuration. Most PSPs migrate to hourly batch within six to twelve months of initial deployment as the operations team develops confidence in the system's behavior.
How does liquidity buffer sizing work?
At $10 million in average deployed float earning 6% APY, a fintech generates $600,000 per year in yield revenue with no changes to the user-facing product. RebelFi's 15% fee on yield generated leaves the fintech with $510,000 net annual yield revenue.
The most consequential design decision in yield-in-transit architecture is not vault selection or sweep cadence — it is the size of the instant-access liquidity buffer maintained outside yield positions. Size the buffer too large and you leave yield on the table. Size it too small and you face a payout delay when settlement demand spikes.
Buffer sizing methodology
Buffer sizing is a data problem. The starting point is your settlement velocity data: actual payout patterns by day of week, time of day, merchant category, and hold type. The buffer should be sized to cover peak payout demand within a single settlement batch, with a margin above the historical 99th percentile spike.
A practical formula for initial buffer sizing:
``` Buffer = (Peak daily payout demand) × (Settlement batch duration) × (Spike factor) ```
Where:
For additional context, see our guide to **stablecoin on/off ramp integration guide**.
Peak daily payout demand: Highest observed single-day payout volume in the trailing 90 days
Settlement batch duration: Hours between batch runs (e.g., 0.5 for a 30-minute batch cycle)
Spike factor: 1.3-1.5 for established processors with stable merchant mix; 1.5-2.0 for processors with high merchant churn or volatile volume
For a processor running $50M daily payout volume, 30-minute batch cycles, and a 1.4 spike factor:
``` Buffer = $50M × (0.5/24) × 1.4 ≈ $1.46M ```
That buffer covers the worst observed single-batch demand at a 40% safety margin. The remaining $48.5M+ in daily float is available for yield deployment.
For additional context, see our guide to **stablecoin float yield for fintechs**.
Dynamic buffer management
Static buffer sizing is a starting point, not a steady state. A well-tuned implementation adjusts the buffer in response to observed settlement patterns, merchant risk signals, and day-of-week variance.
Dynamic buffer management uses trailing settlement data to increase the buffer ahead of historically high-volume periods (end-of-month merchant settlements, pre-holiday volume spikes) and reduce it during predictably low-volume windows. This keeps the yield-optimized pool as large as possible while maintaining the liquidity guarantee.
Morpho Protocol holds over $4 billion in total value locked in isolated lending markets on Ethereum and Base. Its per-market isolation means a problem in one collateral category does not affect USDC lenders elsewhere, providing a more conservative risk profile than pooled lending protocols.
How Should PSPs Choose Yield Vaults for Settlement Float?
Not every yield venue is appropriate for settlement float. The float has a non-negotiable exit constraint: funds must be available within approximately 30 seconds when a payout batch runs. This constraint eliminates yield venues that do not meet specific liquidity, custody, and withdrawal latency requirements.
Minimum requirements for settlement float vaults
Withdrawal latency: The vault must support withdrawals that complete within the processor's payout SLA. For real-time and hourly batch operations, this means on-chain withdrawal finality under 60 seconds. Venues with unstaking queues, multi-day redemption windows, or liquidity-dependent exit times are not suitable for primary float allocation.
Custodial transparency: Settlement float held in yield positions must be verifiably attributable to specific pool categories under MiCA, GENIUS Act, and money transmitter license frameworks. Venues that cannot provide real-time on-chain attestation of the processor's position — or that commingle institutional and retail positions without attribution — create compliance reporting problems.
Counterparty concentration limits: No single yield venue should hold more than a defined percentage of total deployed float. A 20-25% maximum per venue is a reasonable starting point for PSPs with diversified vault access. This protects settlement liquidity in the event of a single venue's temporary withdrawal constraints.
Minimum rate threshold: Each venue must clear a net yield hurdle after withdrawal fees, gas costs, and any management fees. Venues that net below the hurdle under current market conditions should not receive active allocation until conditions change.
Vault categories by suitability
Tokenized T-bill funds (highest suitability for primary allocation): Funds like BUIDL and OUSG hold short-duration U.S. Treasury securities and pass through yield continuously. Withdrawal latency is low for the primary share class. Counterparty risk is U.S. government credit risk, which is the lowest available. These venues are appropriate for 40-60% of deployed float at most PSPs.
Stablecoin issuer reward programs (high suitability for secondary allocation): USDC and EURC issuers offer institutional yield programs that accrue directly on the stablecoin balance. No conversion step is required for deployment or withdrawal. Latency is effectively zero. Rates are lower than T-bill venues but the operational simplicity is high. Appropriate for 20-30% of deployed float.
Institutional lending protocols (moderate suitability, concentration limits apply): On-chain lending venues with institutional-grade counterparty controls can offer higher rates than T-bill funds. Withdrawal latency is generally low for standard positions but increases during periods of high protocol utilization. These venues should be capped at 15-20% of deployed float to limit withdrawal latency risk during market stress.
Kamino Finance on Solana holds over $1.7 billion in TVL, delivering 5-8% APY on USDC with sub-second deposit and withdrawal composability essential for high-frequency payment use cases.
Higher-yield on-chain strategies: Some venues offer materially higher APY through more complex strategies. These are not appropriate for primary settlement float allocation. They may be suitable for the tail of the float that has the longest predicted hold times, with explicit withdrawal latency monitoring and automatic rebalancing triggers.
How Do You Design Automated Sweep Rules for PSP Float Yield?
Sweep rules are the operational brain of the yield-in-transit system. They define when to deploy, where to deploy, how much to allocate per venue, and when to rebalance or withdraw. Rules must be explicit, auditable, and designed to handle edge cases without manual intervention.
Core rule categories
Deployment trigger rules: Define the conditions under which cleared float is swept into yield positions. At minimum: minimum float amount per sweep (to avoid uneconomical small-position management), KYT clearance status required, and hold-time minimum before deployment (float expected to settle in under four hours should stay in the instant-access buffer, not in yield positions).
Allocation rules: Define the target allocation across vault categories. Specify maximum concentration per venue, minimum rate hurdle for activation, and rebalancing band — the acceptable deviation from target allocation before automatic rebalancing is triggered.
Withdrawal scheduling rules: For each active yield position, the system calculates the expected settlement date for the corresponding float and schedules a withdrawal to arrive in the payout pool with sufficient lead time. The withdrawal should be scheduled to complete at least one full batch cycle before the expected payout — not triggered by the payout itself.
Rebalancing rules: When a vault's rate drops below the minimum hurdle, or concentration exceeds the maximum limit, funds are automatically redeployed to alternative venues. Rebalancing events are logged with pre- and post-rebalance position snapshots for audit purposes.
Emergency withdrawal rules: If the instant-access buffer falls below a defined minimum due to unexpected settlement demand, the system triggers automatic partial withdrawal from the nearest-maturity yield positions to restore the buffer. This rule executes without human authorization and logs the event for post-hoc review.
Frequently Asked Questions
What is stablecoin yield infrastructure?
Stablecoin yield infrastructure is the software and API layer that routes idle USDC or USDT balances to DeFi lending protocols, generates interest income, and returns funds on demand. Enterprise stablecoin yield platforms like RebelFi handle protocol selection, position monitoring, yield optimization, and risk management, delivering a simple API interface: deposit, withdraw, and check balance. The underlying protocols — Aave, Morpho, Kamino, and Compound — are audited, overcollateralized lending markets where yield is generated by paying borrowers who post collateral exceeding the loan value. Lenders have never lost principal on Aave across $1 trillion in cumulative volume.
What APY can fintechs earn on stablecoin balances?
Fintechs deploying USDC through RebelFi earn 4-7% APY on the standard tier via Aave, Morpho, and Kamino. The managed tier delivers 7-11% APY using delta-neutral strategies that combine lending yield with basis trades and liquidity provision. Standard tier rates are variable and track real-time borrowing demand; managed tier rates are more stable due to their multi-strategy composition. At $10 million in average deployed float, the standard tier generates $400,000-$700,000 per year in gross yield. After RebelFi's 15% fee, the fintech retains $340,000-$595,000 annually.
How does RebelFi's non-custodial model work?
RebelFi generates unsigned yield transactions specifying the deposit amount, target protocol, and wallet address, then passes them to the client's key management infrastructure for signing. The client's HSM, MPC wallet, or hardware security module authorizes and broadcasts the transaction. RebelFi has no technical capability to move funds without client authorization. This non-custodial architecture means clients retain full on-chain custody, satisfy most e-money and payment license requirements without additional authorization, and maintain complete audit trails of all yield positions. The model is supported on Solana, Ethereum mainnet, and Base.
What protocols does RebelFi use for yield generation?
RebelFi routes yield through four audited protocols: Aave, Morpho, Kamino, and Compound. Aave has processed over $1 trillion in cumulative lending volume with zero lender principal losses. Morpho holds over $4 billion in TVL with isolated markets that prevent cross-market contagion. Kamino is Solana-native with $1.7 billion in TVL and sub-second composability for payment flows. Compound has operated since 2018 with a consistent risk track record. Protocol selection is automated based on real-time APY comparison, liquidity depth, and the client's chain and liquidity preference. Clients can override the routing to specific protocols if required by their compliance policies.
How long does integration take?
A fintech with existing USDC wallet infrastructure can integrate RebelFi's yield API in 2-4 weeks. Week one covers API authentication, sandbox testing, and initial deposit flows. Week two covers compliance review of the yield architecture — specifically the non-custodial transaction flow and treasury segregation model. Weeks three and four cover staging environment testing and production cutover with monitoring dashboards. Fintechs without existing USDC signing infrastructure may require an additional 2-4 weeks. Building equivalent capability in-house typically takes 6-18 months and costs $800,000-$2.4 million in engineering, compliance, and licensing expenses.
Is stablecoin yield compliant with financial regulations?
Stablecoin yield on company treasury funds is broadly compliant under most financial regulatory frameworks, including US money transmitter licenses, EU e-money institution frameworks, and UK FCA authorization. The critical compliance variable is the source of funds: yield on company treasury USDC is treated as ordinary investment income; yield on customer deposits faces additional restrictions under MiCA Article 54 and equivalent frameworks. RebelFi implements a three-wallet segregation architecture — operational wallet, yield wallet, and customer custody wallet — that satisfies most regulatory requirements. Fintechs receive a compliance documentation package for regulatory review.
What chains does RebelFi support?
RebelFi supports stablecoin yield on Solana, Ethereum mainnet, and Base. Solana is recommended for high-frequency payment flows requiring sub-second transaction finality and sub-cent transaction costs — Kamino on Solana delivers 5-8% APY with withdrawal finality in under 5 seconds. Ethereum mainnet provides the deepest liquidity through Aave and Morpho, appropriate for large institutional positions above $10 million. Base offers Coinbase infrastructure backing with Ethereum-level security at 10-100x lower transaction costs, suitable for mid-market fintechs. Arbitrum is not currently supported. Tron is on the roadmap.
What does RebelFi charge for yield infrastructure?
RebelFi charges approximately 15% of yield generated, calculated as a share of gross APY. There are no flat fees, setup fees, or minimum volume requirements on the standard tier. For a fintech with $10 million in deployed float earning 6% APY, the gross annual yield is $600,000; RebelFi's fee is $90,000; the fintech retains $510,000 net. The B2B2C pricing model for partners sharing yield with customers charges 15% of the partner's net margin rather than 15% of gross yield — ensuring RebelFi's fee scales with the partner's actual profitability. Enterprise volume pricing is available at $50 million or more in average deployed float.