Wave-1 in 90 days: how a cross-border corridor actually ships.

A field note on the engineering, licensing, and BSS integration sequence required to go from signed term sheet to a live remittance corridor — with real timelines and where deals typically break.

The question every CTO asks in week two

The first meeting is usually strategic. The second is usually the CTO arriving with a yellow notepad and a single question written at the top: "What does Day 1 actually look like?"

Not Year 3. Not the £165M uplift model. Day 1. The thing that goes live.

This is that answer. It is a field note from the engineering and integration sequence we run to deliver a cross-border remittance corridor — Wave-1 in the three-wave deployment model. No operator names. Real timelines. Real blockers.

What Wave-1 is — and is not

Wave-1 scope (90 days):

• One remittance corridor: one origin market, two destination markets
• Partner-bank EMI wallet (licensed, no own-EMI acquisition required)
• Billing-adjacent integration: read-only event bus from the operator's BSS
• 100k registered users target
• $20M cumulative transfer volume
• Single-digit % take rate

Wave-1 is explicitly not:

• IBAN-backed wallet issuance (Wave-2)
• Virtual debit card (Wave-2)
• Investment or micro-savings product (Wave-3)
• Any write path to the operator's OCS, HLR, or subscriber records (ever)

The constraint is intentional. The fastest path to live revenue is the narrowest product that has regulatory cover, works on the BSS event bus read-only, and requires no subscriber-record changes. The CTO's biggest concern — "you are replacing our billing system" — is answered by design, not by promise.

The 90-day sequence

Days 1–14: legal and licensing perimeter

The first two weeks are not engineering. They are legal.

The licensing posture for Wave-1 depends entirely on where the operator is headquartered:

In practice, the legal perimeter meeting takes three to four sessions. The typical delay: the operator's legal team does not know whether their existing MSB licence covers digital remittance. It usually does. But confirming this takes two weeks.

Action for the operator: Assign one person from legal who owns the MSB/PI licence file and can answer questions in 24 hours. This single decision has more impact on go-live date than any engineering decision in the first month.

Days 14–30: BSS integration scoping

The BSS integration for Wave-1 is read-only. We need three event types:

1. Top-up event — subscriber initiated a prepaid top-up or postpaid payment
2. SIM activation event — new SIM registered (used for wallet KYC anchor)
3. Roaming event — subscriber entered a corridor-relevant country (optional, improves conversion)

These events are already on the operator's billing event bus (Amdocs, Ericsson, Netcracker, or Optiva depending on vintage). We never write to OCS. We never touch subscriber records. We connect via a read-only consumer on the event bus with a single config entry.

Typical integration effort by BSS stack:

The integration is reversible. A single config change removes the consumer. No data persists inside the operator's network perimeter.

Where this breaks: The BSS team has not exposed event bus access to third parties before. The firewall rule to allow outbound events to our ingestion endpoint requires a network change request. This NCR typically takes 10–15 business days inside a telco. File the NCR in week two, not week four.

Days 30–60: product build and KYC pipeline

The product layer — the wallet app, the corridor UI, the KYC flow — runs in parallel with BSS integration. The critical path is KYC.

The KYC pipeline for Wave-1 is a three-step sequence:

1. ID document capture — front and back of national ID or passport
2. Liveness check — passive liveness via device camera
3. Sanctions screening — real-time check against OFAC, UN, EU consolidated list

Pass rate at step 3 depends on corridor. For an EU/CIS corridor with diaspora sender population, expect 85–92% auto-approve on first attempt. The remaining 8–15% go to manual review queue.

The SIM-as-anchor pattern: Where the operator provides a SIM activation event (Days 14–30 above), we use it as a secondary identity signal. A subscriber who has held an active SIM for 18+ months with no fraud flags gets a lighter KYC path. This improves pass rate by 6–9 percentage points and reduces manual review volume significantly.

Days 60–85: corridor testing and soft launch

The corridor enters testing at day 60 with a closed group of internal users, then a soft launch at day 75 with an invite-only cohort from the operator's existing customer base.

What we test:

• End-to-end transfer: origination → KYC → wallet credit → corridor routing → destination payout
• Reconciliation: every transfer must post to the ledger within 90 seconds and settle T+1 with destination partner
• Failover: we test corridor partner failover (two destination partners configured from launch)
• Rollback: we verify the BSS consumer can be disabled in under 5 minutes

The soft launch target is 500–1,000 transfers in the first 10 days. Volume is intentionally low. We are testing the reconciliation loop, the dispute handling path, and the customer support escalation flow — not throughput.

Days 85–90: public launch

Public launch is gated on three conditions:

1. Reconciliation clean — no unreconciled transactions in the preceding 48 hours
2. Support capacity confirmed — operator's tier-1 support trained on the dispute flow
3. Regulatory notification filed — applicable notification to the payment regulator in origin market (where required; most EEA jurisdictions do not require pre-launch notification for partner-bank EMI operations)

Where deals break — the honest list

After running this sequence multiple times, the failure modes are predictable:

1. Legal delay on MSB/PI licence scope (most common) Operator legal team cannot confirm licence scope in time. Timeline slides by 3–4 weeks. Fix: involve legal in week 1, not week 3.

2. NCR delay on BSS firewall rule Network change request takes 4–6 weeks inside the operator's network team. Fix: file the NCR as soon as BSS scoping is complete (day 21 at the latest).

3. KYC vendor SLA mismatch The operator has an existing KYC/identity vendor. Their API does not support passive liveness. Switching vendors mid-project adds 3–4 weeks. Fix: confirm KYC vendor capability at day 14 during BSS scoping week.

4. Reconciliation spec not agreed The accounting team wants daily batch reconciliation. The product requires real-time. Aligning the reconciliation spec with the operator's finance team adds 2–3 weeks if not scoped upfront. Fix: include finance in the week-2 scoping session.

5. Product scope creep The marketing team wants to launch with a loyalty integration, a referral mechanic, and a promotional landing page. None of these are in Wave-1 scope. Each adds 1–2 weeks. Fix: publish the Wave-1 scope document in week 1 and reference it in every meeting.

What 90 days produces

A corridor that has passed the sequence above delivers, by day 90:

• Live product — end-to-end transfer working in production
• KYC pipeline — auto-approve running at 85%+ pass rate
• Ledger — every transaction posted, every reconciliation clean
• Audit trail — every event logged, timestamped, and exportable for regulatory review
• Rollback path — BSS consumer removal tested and documented, reversible in under 5 minutes

The business KPIs from a live corridor — 100k users, $20M volume, single-digit take rate — follow from the product being live and reachable. Marketing and growth are operator-side. The engineering deliverable is a product that works reliably and reconciles cleanly.

The CTO's question, answered

Day 1 is a cross-border corridor. It is read-only against the BSS. It does not touch subscriber records. It does not require a licence acquisition. It ships in 90 days.

Wave-2 — wallet and card — comes in months 4–12. Wave-3 — investments and SME — in months 12–36.

The notepad question has an engineering answer. The rest is sequencing.

Field notes reflect our direct delivery experience. Timelines and pass rates are indicative and vary by operator profile, BSS vintage, and jurisdiction. All operator data in this note is anonymous or composite. For a wave-plan scoped to your specific BSS stack and regulatory perimeter, book a working session →