> Implementation & Go-Live | ExpandUp Architecture Method
Architecture — Implementation & Go-Live

Implementation is where the
architecture gets defended.

Vendor proposals, bank requirements, and timeline pressure all push toward shortcuts at launch. The architecture needs someone in the room who knows what it was designed to do — and why the shortcuts undermine it.

Talk with us before your next vendor decision → ← Architecture Overview
Architecture Defense

What gets eroded during implementation

The architecture was designed to capture interchange, structure float economics, and build a compliant program. Implementation pressure can erode each of these — without anyone recognizing what's being given up.

EROSION PATTERN 01
Vendor proposes different economics in the final contract
Term sheets get modified in contract negotiations. Interchange sharing terms shift. Take rates change. Someone needs to catch this and push back with the original architecture as the reference point.
EROSION PATTERN 02
Bank changes compliance requirements mid-onboarding
Bank risk committee raises new requirements after term sheets are signed. The program has to decide what to redesign and what to defend. Without architecture clarity, everything gets redesigned to fit the new requirement.
EROSION PATTERN 03
Timeline pressure trades economics for speed
"We can launch faster if we accept the vendor's default interchange structure." The tradeoff is real — but the cost of the shortcut gets underestimated. The architecture was designed to avoid exactly this tradeoff.
EROSION PATTERN 04
Last-mile gaps across parties surface at launch
Bank, processor, compliance vendor, and product team all have different understandings of who owns what. The gaps surface at go-live — when they're most expensive to resolve.
Last-Mile Gap Analysis

The gaps that appear in every program between design and launch

The rails work. The bank relationship exists. But the operational system connecting the technology to real business workflows is incomplete. Vendor data management, payment orchestration, reconciliation logic, and onboarding infrastructure are absent — and without them, the program never functions in practice. This is the last-mile gap that neither the bank nor the infrastructure provider is positioned to close.

GAP 01
Operating model between bank and program
Exactly who handles compliance escalations, dispute resolution, and bank-required reporting. Usually assumed by both parties — and different assumptions.
GAP 02
Data flow between infrastructure and compliance
Transaction data required for OFAC screening, SAR filing, and bank reporting needs to flow to compliance in a specific format and cadence. Often not designed until testing reveals the gap.
GAP 03
Exception handling and escalation paths
What happens when a transaction fails compliance screening? Who decides? In what timeframe? Which system owns the decision? Usually undefined until the first exception surfaces.
GAP 04
Reconciliation between infrastructure and ledger
How transaction-level reconciliation works across processing, settlement, and ledger systems. Often not fully designed until the first settlement cycle.
GAP 05
Customer onboarding KYC integration
How KYC/KYB verification integrates into the customer onboarding flow. What the bank requires versus what the product was designed to collect. Friction in the customer experience often traces here.
GAP 06
Revenue capture verification
How the program verifies that interchange is being captured at the designed rate, float is accruing correctly, and fees are being applied as designed. The economics need to be measured, not assumed.
Implementation Phases

How engagement proceeds through launch

Revenue Verification at Launch

The revenue architecture needs to be verified at launch, not audited six months later.

Interchange capture, float accrual, and fee application all need to be measured from day one. Programs that don't verify revenue architecture at launch discover the economics weren't working six months in — at which point the gap is much harder to close.

See the full monetization framework →

Launch with the architecture intact.

The program was designed to capture specific economics and operate within a specific compliance framework. Implementation is where that design gets tested — and where it needs to be defended.

Talk with us before your next vendor decision → ← Back to Architecture Overview