The executive brief: embedded finance for telecom.
What a telecom CEO, CFO and CTO need to know about embedded finance — in one document. Business case, compliance posture, integration footprint and the 90-day path to first revenue.
This brief is written for the board meeting, not the architecture review. It covers three questions: is the business case real, can we do it without compliance risk, and what does "working with Coreal" actually mean for our IT organisation? The answers are yes, yes, and less than you think.
The business case in three numbers
Telecom operators have always had the best distribution in financial services — they just have not had the platform to use it. Every subscriber already trusts the operator with their identity and their monthly payment. Attaching a wallet, a card and a cross-border transfer service to that existing relationship produces three numbers that are hard to ignore.
The churn number is the one that lands hardest in the CFO meeting. A subscriber with a wallet balance, a card in Apple Pay and an automated family transfer home does not casually port to the competitor. Each financial attachment is a compounding switching cost — and we measure all of them.
The revenue number is derived from a conservative funnel: 10–12% fintech-attach on a 14M subscriber base, blended ARPU of €45–55 per active financial user per year, across four product pools (wallet, card, cross-border, investments). The model is benchmarked against Revolut Standard tier, N26, Wise active customer and Trade Republic blended — not internal projections.
Three leading telecoms have already built this in developing markets: a dominant East African operator (51M users, £1.4B revenue), a pan-African carrier (80M users across 17 markets), and a Latin American operator (18M users, SME attach at 2.4× consumer ARPU). The EU market has better infrastructure, tighter regulation and higher ARPU potential. The only thing missing is the operating layer.
The compliance question
The most common concern at the board level is compliance risk — not "can we build this" but "will we end up in front of the regulator explaining a launch we did not control." The answer is that Coreal is designed to produce evidence, not require it to be assembled after the fact.
Every customer decision — KYC pass, KYC rejection, AML case outcome, dispute decision — is logged with the input state, the policy version applied, the reviewer identity and the timestamp. A regulator can ask for the audit file for any decision taken in the last seven years and it is produced in one click. This is not a compliance feature — it is how the system works.
- DORA ICT risk controls: incident classification, RTO / RPO, supplier testing, change management — all addressed in the platform design, not in a separate compliance workstream.
- PSD2 / EMD2: the licensed entity structure (sponsor bank + Coreal technology + operator distribution) is the standard EU model. No new licence required for the operator in Wave 1.
- MiCA (Wave 5, ring-fenced): if crypto is in scope, it runs in a separate tenant with separate KYT, separate audit log and no connection to the wallet perimeter. The risk cannot leak.
- GDPR: subscriber financial data is processed under the fintech product consent, not the telecom contract. Consent is revocable, logged and auditable. Data minimisation by default.
The compliance question is not "how do we become compliant" — the platform is compliant from day one. The question is "who owns the licence?" and the answer is the sponsor bank in Wave 1, with a path to the operator's own EMI licence in Wave 3 if the business case supports it.
What this means for the CTO
The integration surface is smaller than it looks. Coreal requires read access to three BSS signals (subscriber identity, SIM age and recharge velocity) under explicit subscriber consent, and write access only to its own ledger. It never writes to the telecom billing system, the OCS or the subscriber record.
| What Coreal reads | What it never touches |
|---|---|
| Subscriber identity (SIM-bound, consent-gated) | BSS billing balances |
| SIM age + recharge velocity (risk signal) | OCS real-time charging quota |
| Device fingerprint (session, not stored) | Subscriber records outside consent scope |
| Billing events (webhook, idempotent ACK) | Any write to the telecom core network |
The integration is a standard OAuth OIDC bridge for identity (the telecom IdP becomes an upstream identity provider for the fintech product), a webhook subscription for billing events, and a REST interface to the Coreal ledger for balance queries. There is no mainframe integration work. A competent integration team can land this in a single two-week sprint.
The operator workspace — the UI that the telecom's financial services team opens on Monday morning — is a web application with no native dependency on the telecom's internal systems. Cases, queues, reconciliation views, decision journals. It runs on Coreal infrastructure; the telecom team accesses it via SSO using the same corporate identity they already use.
The 90-day path
Wave 1 is not a "launch event." It is a structured proof: five phases, each with a named output, a sponsor-bank gate and a document a regulator can read. The goal of day 90 is not to have shipped marketing — it is to have shipped a system that works at audit, not just in a demo.
- Day 0–14: Perimeter workshop. Map flows, postings, providers, controls. Name the licensed entity, the technology entity and the distribution entity on the same page.
- Day 15–35: Ledger design + identity bridge. Double-entry posting model, tenant isolation contract, IAM clients. Sample postings reviewed by sponsor-bank risk team.
- Day 36–55: Provider integrations. Sponsor bank, telco billing event webhook, KYC vendor, KYT provider. Every integration enters via a typed adapter. Idempotency required at the boundary.
- Day 56–75: Operator workspace. The cockpit ops actually opens on Monday morning. Cases, reconciliation, decision journals. Built so any decision is one click away.
- Day 76–90: Hardening + regulator dry-run. SRE, DR/BCP, penetration test, evidence-pack dry run with the regulator. Sponsor-bank go-live readiness review.
Eight Wave-1 deployments. Same schedule, same five phases, same named outputs. The discipline is what makes the schedule predictable. Two steering committee members have asked us if we could do it faster — we told them the same thing both times: 90 days is not a minimum viable effort, it is a minimum viable result.
What "working with Coreal" looks like
The engagement starts with a four-hour working session — not a pitch, a working session. We map your subscriber base, your current churn dynamics, your existing fintech product if any, and your licensed entity structure. We identify what is already built and what is bespoke. At the end of the session, you have a one-page perimeter brief that a regulator can read and a preliminary business case with your numbers.
From the working session, a Wave-1 deployment agreement covers: the 90-day schedule, the sponsor-bank engagement, the technical integration scope and the operator workspace. There is no multi-year consulting engagement required to get to a live product.
The commercial model is a platform fee plus a revenue share on fintech pools — aligned incentives, not a fixed-cost infrastructure contract. Coreal does better when you do better. That is the structure we offer to every partner, and it is the reason we have built the platform to produce evidence instead of requiring it.