"We launched something but results aren't matching expectations."
The problem you see is rarely the first problem you need to solve. Most embedded finance underperformance traces back to architecture decisions made before launch — and the recovery sequence matters as much as the diagnosis.
What this stage actually looks like
The program is live. But revenue is below forecast, customer adoption is lower than projected, STP rates are disappointing, or the economics don't match what the business case assumed. Something is underperforming — and the question is what, exactly, and in what sequence to address it.
The challenge at this stage is that the visible problem is rarely the root problem. Low VCard acceptance rates are a symptom — the root cause might be supplier enrollment gaps, AR integration failures, or BIN economics that made the program uncompetitive. Interchange below forecast might point to BaaS middleware share, the wrong BIN category, or Level 2/3 data not being transmitted. Each symptom has multiple possible causes, and treating the symptom without diagnosing the cause produces incremental improvement at best.
The pattern ExpandUp sees most frequently: organizations optimize what they can measure (payment volume, acceptance rate, exception rate) rather than what is actually constraining the program (program model economics, BIN economics, compliance posture, supplier AR integration). The diagnostic needs to start with the architecture, not the metrics.
The decisions and risks specific to this stage
- →Processor spread — the gap between your stated rate and actual interchange captured is the most common and most overlooked leakage source.
- →BaaS middleware share — if you are on a BaaS program, the middleware layer is capturing 40–60% of interchange that a direct bank program would pass through to your program.
- →Float not negotiated — BaaS programs retain yield on your customer balances by default. At $2M average daily balance, 4.5% annualized is $90K/year left on the table.
- →Level 2/3 data gaps — B2B card transactions that don't transmit purchasing card data downgrade from commercial rates (175–250 bps) to standard rates (100–130 bps) on every transaction.
- →VCard STP rate below 25% — each failed VCard auto-apply is either a manual AR processing cost at the supplier or a conversion to ACH at zero interchange. Getting STP above 40% is worth more than almost any other optimization.
- →Fee structure absent or unenforced — monetized ACH, speed premium fees, and enhanced remittance fees are revenue lines that either exist or don't based on whether they were designed into the program.
What we do at this stage
At the Optimizing stage, ExpandUp starts with a program economics diagnostic — working through each potential leakage source to quantify what it is costing and what the recovery sequence looks like. The leakage calculator is a starting point; the full diagnostic goes deeper into program model structure, BIN economics, BaaS commercial terms, and STP infrastructure.
The recovery sequence matters. The fastest recoverable economics are usually the ones that don't require bank renegotiation — Level 2/3 data transmission, fee structure implementation, monetized ACH rollout. The largest recoverable economics usually require bank structure changes — BaaS to direct migration, BIN renegotiation, float yield negotiation. We help you sequence both.
We have operated programs at $350M in annual AP payments revenue and know exactly where the economics go. The diagnostic is fast because we know what to look for — and the recovery roadmap is grounded in what actually works at scale, not in theory.