Day-by-day deliverables for a telco × bank Wave-1 deployment. Phases, owners, named outputs, dependencies, gates. The artefact a programme manager hands to the steering committee.
A Wave-1 deployment is not a launch. It is the proof — to the sponsor bank, to the regulator, to the steering committee — that the design we agreed on actually works in production. The customer-facing surface is small (typically wallet top-up + autopay). The supporting machinery is large (ledger, BPM, gateway, operator workspace, journal). The 90-day plan is how we ship the second without rushing the first.
| Phase | Window | Output | Approver |
|---|---|---|---|
| 1. Perimeter | Day 0–14 | 1-page perimeter brief | Steering committee + sponsor-bank risk team |
| 2. Ledger + IAM | Day 15–35 | Schema, RLS policies, sample postings | Sponsor-bank tech lead + 2L compliance |
| 3. Provider integrations | Day 36–55 | Gateway config + idempotency contract | 1L tech lead + provider counterparts |
| 4. Operator workspace | Day 56–75 | Case queue, recon view, journal export | Head of operations + 2L compliance |
| 5. Hardening + dry-run | Day 76–90 | Production-grade Wave-1 wallet | Sponsor-bank go-live committee |
A perimeter is three things named on the same page: the licensed entity, the technology entity, and the distribution entity. For a Wave-1 wallet that is typically: sponsor bank (license), Coreal (technology), telco (distribution). Each has a named accountable executive. Each has a named delegate for the programme. The names go on the brief, the brief goes to the steering committee, and nothing else moves until the brief is signed.
The double-entry posting model is designed for every flow named in the brief. For each flow, we produce: the typed accounts that participate, the example postings (debit-credit pairs), the journal name, the idempotency contract. Sample postings get reviewed by sponsor-bank risk — they need to recognise their accounting view in our ledger view.
Tenant isolation is wired in parallel: separate IAM clients, RLS predicates on every table, network-namespace boundary, audit-log partitioning. Each layer is testable; we run a tenant-isolation acceptance test that confirms a Tenant-A token cannot read Tenant-B data at any layer. The result lands in the audit register.
The sample postings will not match the sponsor bank’s accounting view on the first attempt. There is always a sub-ledger interpretation difference (when does treasury safeguarding move, what triggers a settlement). The phase budget includes a week for the disagreement-and-reconciliation conversation.
Sponsor bank, telco billing, KYC vendor, KYT provider — each enters via a typed gateway adapter. Each adapter implements the same contract: initiate, confirm, cancel, status, settle. Idempotency-keys are required at the boundary, not optional. The provider may have its own idempotency model; the adapter translates.
The contract negotiation with each provider is the slow part. Sponsor bank wants their template DPA; we want our standard schedule. The KYC vendor wants to see our retention policy; the KYT provider wants to see our data residency. Phase 3 includes a named legal point of contact on each side. The technology hits production typically by day 50; the contracts close by day 55 with grace periods.
The cockpit ops actually opens on Monday morning. Three role-bound personas: payment ops (queue), compliance (cases), treasury (reconciliation). Each persona sees the SLAs they are accountable for, with breaches in red. The journal export view is wired so that any case from any persona can be exported in the format the regulator accepts.
The workspace is built so that the ops team learns it before the customer-facing surface launches. Day 70 is the first dry-run: the team handles synthetic cases at Wave-1 scale, with the same SLAs that will apply on day one. Coverage gaps surface here; we fix them before the real customers arrive.
The technology and the team are in production state by day 75. Phase 5 is the proof that they will hold under stress. SRE: chaos engineering on the gateway, the BPM, and the ledger. DR/BCP: failover to the secondary region with real traffic. Pentest: independent CREST-accredited firm runs against the full surface. Regulator dry-run: mock evidence-pack pull against a random sample of synthetic cases.
Day 90 is the sponsor-bank go-live committee. They review: the pentest report, the DR/BCP exercise, the regulator dry-run, the operator-workspace incident-response drill. They approve, conditionally approve, or defer. Conditionally approve usually means a 10-day extension on phase 5, never a return to earlier phases. Defer is rare; when it happens, it is because of an external change (regulatory letter, sponsor-bank reorganisation, sanctions update) that warrants the wait.
Wave-1 customers arrive in cohorts, not in a launch event. The first cohort is internal — staff at the telco, staff at the sponsor bank, staff at Coreal. Bugs surface, get fixed, get patched. Cohort 2 is friends-and-family; cohort 3 is the first 5,000 telco customers selected by tenure and risk profile. Within 6 weeks of day 90, the platform is at Wave-1 production scale (typically 50,000–150,000 customers). At that point, Wave-2 planning begins — and the same five-phase schedule applies, with different outputs.
The runbook does not cost less than 90 days. We have tried — at 60 days, the sponsor-bank go-live committee defers; at 75 days, the operator workspace is undertrained; at 90 days, with good discipline, it lands. We have observed the same number across eight Wave-1 deployments. The discipline is what makes the schedule predictable; the schedule is what makes the steering committee sign.