One Customer. One Truth.
Telecom mergers don't fail at the network layer. They fail when two billing systems each believe the same customer is a different person. Lumen resolves that — before migration day, not after.
Lumen
01
Multi-source identity consolidation. Lumen ingests subscriber records from both operators simultaneously — MSISDN, name, DOB, address, email — and builds a unified party index without requiring a shared primary key.
02
Signal-weighted matching engine. Each candidate pair is scored across six independent signals — phone, name+DOB, email, address, fuzzy name — with configurable confidence bands. HIGH, MEDIUM, and LOW confidence matches follow different resolution paths.
03
Wave-based migration architecture. Structured pre-migration, during-migration, post-migration, and reconciliation phases ensure data quality at every stage — not just at cutover. Each wave is independently auditable.
04
GDPR-ready golden records. Lumen writes a single authoritative party record into the target BSS, with a full audit trail linking every source identity. Erasure requests and subject-access requests are resolved in seconds, not weeks.
Built for the Complexity of Telco Mergers.
A telecom merger involves millions of customer records, dozens of product types, and two completely different data models. Lumen was designed from the ground up for this environment. It handles PAYM, PAYG, broadband, and enterprise B2B subscribers within a single pipeline — without needing a shared schema across the two source systems.
Where confidence is high, Lumen acts automatically. Where confidence is medium, it routes to a structured human review queue with pre-loaded context. Where data is ambiguous, it preserves both records and flags them for reconciliation. Nothing is silently dropped. Every decision is auditable. The result is a golden record in your target BSS that your business can trust on day one.
6
Matching Signals
90pts
Auto-Link Threshold
Wave N
Incremental by Design
100%
Audit Coverage
0
Hardcoded Thresholds
The Real Cost of Duplicate Identity
Your customers are already living in both worlds. Your systems aren't.
Every week that passes with unresolved identities is a week of missed cross-sell, duplicate outreach, failed service changes, and regulatory exposure. These are not hypothetical risks — they are happening today.
Mobile — PAYM
The Dual-Network Family
A household has four lines — two on Operator A Pay Monthly, two on Operator B. They call to ask about a converged family plan. Your agent runs four separate lookups across two systems, sees no connection between them, and cannot offer a unified deal. The customer hangs up and stays on two bills.
Broadband + Mobile
The Invisible Broadband Customer
A Operator B broadband customer migrates to a Operator A mobile contract as part of a bundle offer. In your CRM, they are two separate people. Marketing runs a retention campaign for "at-risk mobile-only customers" — and targets someone who has just committed to a two-year broadband contract. The offer undermines the relationship.
PAYG
The Pay-As-You-Go Ghost
A PAYG customer on Operator B top-ups regularly, has never provided an email address, and changes handset number every 18 months. When they appear in Operator A's system from a store interaction, there is no email match, no MSISDN match, and an approximate name. Without intelligent fuzzy matching and postcode correlation, they are created as a new record — twice.
Enterprise B2B
The Corporate Account Nobody Owns
A 500-seat enterprise has procurement through Operator A's CRM and devices through Operator B's BSS. Their legal entity name differs slightly between systems ("Acme Ltd" vs "ACME Limited"). No Companies House lookup was ever performed. Your account teams are calling the same company from two different regions, each unaware the other exists.
GDPR / Erasure
The Erasure Request You Can't Honour
A customer exercises their Right to Erasure. Your DPO identifies and removes them from one system. Six months later, a Subject Access Request reveals their data still exists under a different ID in the other operator's records. The ICO inquiry is not hypothetical — it is a question of when, not if.
Billing + Loyalty
The Customer Who Gets Billed Twice
A roaming charge hits a customer who has two SIMs — one from Operator A, one from Operator B. Both billing systems generate separate usage alerts. The customer receives two confusing messages about the same trip. Loyalty points accrue on neither account in full. They are loyal to two operators and feel valued by neither.
"The challenge isn't migrating products or systems. It's knowing, with certainty, that the person in System A and the person in System B are the same human being — and being able to prove it to a regulator."The Identity Problem — Every Telco Merger, Eventually
End-to-End Programme Support
Built for how mergers actually work — not how they were planned.
Lumen supports every phase of your consolidation programme. From profiling raw extracts on day one to ongoing reconciliation years into the merged entity — it is designed to grow with you, wave by wave.
Pre-Migration — Discover & Prepare
Before you link a single record, understand what you have.
Lumen's data profiling job analyses your raw extracts — before any matching — to surface the true shape of your data. Segment boundaries, signal availability, and data quality gaps are identified here, not discovered mid-migration.
Ingest raw source extracts (CSV, JSONL, S3)
Profile field completeness per source and product line
Identify high-frequency emails and shared MSISDNs
Discover natural segments (PAYM, PAYG, Broadband, Enterprise)
Configure signal weights per segment — no code deployment
Dry-run matching pass — see projected match rates before going live
Tune thresholds; re-run dry-run until match rates are acceptable
Validate control totals before committing any records
During Migration — Wave-by-Wave Consolidation
Not a one-time big bang. A controlled, incremental build-out.
Real migration programmes don't move everything at once. Lumen's wave architecture means each new data source — mobile today, broadband next quarter, business accounts next year — matches against what's already been consolidated. The golden record grows richer with every wave.
Wave 1: Operator A mobile + Operator B mobile → unified golden records
Wave 2: Broadband customers matched against already-consolidated identities
Wave 3+: Any subsequent system, product line, or region
SHA-256 content hashing prevents re-processing identical records
Delete safety guard — suspicious bulk deletes blocked and alerted automatically
Dead-letter queue captures every failed record for manual replay
High-confidence pairs linked automatically (≥90 points)
Medium-confidence pairs routed to analyst review queue
Low-confidence records kept separate — never incorrectly merged
Kafka events emitted for every state change — downstream systems stay in sync
Post-Migration — Live Golden Records
The migration completes. The identity platform lives on.
Once waves are complete, Lumen continues to serve lookup queries and maintain the golden record as source systems are updated. Manual corrections — merges, splits, deactivations — are handled through the admin API with full audit coverage.
REST API for all downstream services to resolve identity
Lookup by any source system ID (or any external reference)
Merge two incorrectly separated parties (admin-initiated, full audit trail)
Split an incorrectly merged party back into two separate identities
Delta ingestion for ongoing source system changes (daily at 02:00)
Redis-cached lookups — sub-millisecond for already-resolved IDs
Event streaming — downstream CRM, billing, loyalty stay current
Organisation hierarchy resolution — parent/child enterprise accounts
Ongoing — Reconciliation & Drift Detection
Source systems change. Lumen detects it before your customers do.
A weekly reconciliation job compares every active identity against its source records. Address changes, new MSISDNs, closed accounts — any drift between the golden record and the source is surfaced, quantified, and actioned before it becomes a customer-facing problem.
Weekly full reconciliation — Sunday 02:00 UTC by default
Attribute drift detection — compare golden record to current source data
MSISDN or email changes → automatic re-evaluation of match pairs
Deleted source records → link flagged for review, not silently removed
Count reconciliation — Lumen count vs source control total, alerting on >0.5% discrepancy
Reconciliation report generated per run — exportable for programme governance
PagerDuty alerting for critical discrepancies; Slack for warnings
All findings written to append-only audit log
Wave Architecture
From first mobile extract to full estate consolidation.
Each wave adds a new dimension to the golden record. From Wave 2 onwards, TMF632 — not the source system — is the matching target. Every new record is matched against what is already known.
Wave 1
Mobile — Both Operators
- Operator A mobile (PAYM + PAYG)
- Operator B mobile (PAYM + PAYG)
- Initial golden records created
- TMF632 party stubs published
Wave 2
Broadband — Operator A
- Broadband subscriber extract
- Match against existing TMF632
- PATCH existing records (add service ref)
- Create new where no match found
Wave 3
Broadband — Operator B
- Broadband subscriber extract
- Match against now-richer TMF632
- Cross-operator broadband matching
- Review queue for borderline cases
Wave N
Enterprise Accounts & Future Systems
- B2B organisations (Companies House enrichment)
- Parent/child hierarchy resolution
- Contact individuals linked to orgs
- Any future source system or product
Key insight: From Wave 2 onwards, Lumen maintains a lightweight PostgreSQL index mirror of TMF632 for high-speed blocking lookups — so matching against millions of already-consolidated records takes milliseconds, not minutes.
Intelligent Matching Engine
Six signals. Configurable weights. Zero hardcoded assumptions.
Every signal carries a configurable point value. Thresholds are stored in the database — not in code — so they can be tuned per segment, per product line, or per wave, without a deployment.
Individual Matching Signals
MSISDN (mobile number) — exact
E.164 normalised; intersection of both number arrays
40 pts
Name + Date of Birth — exact
Canonical first + last name, ISO 8601 DOB
35 pts
Email address — exact
Lowercase normalised; high-frequency addresses excluded
20 pts
Name + Postcode — exact
Canonical full name and PAF-format postcode
20 pts
Fuzzy name — Jaro-Winkler ≥ 0.92
Catches transcription errors and name variants
10 pts
Date of birth — tiebreaker
Used as additional signal when name match exists
10 pts
Organisation Matching Signals
Companies House / VAT / DUNS number
Deterministic — a single match alone triggers auto-link
100 pts
Trading name — exact
Normalised legal trading name
40 pts
Legal name — exact
Registered legal entity name
35 pts
Confidence Levels & Actions
Smart Disambiguation Rules
→ Common names (e.g. "John Smith" in >0.5% of records) require a corroborating MSISDN or email to reach HIGH — postcode alone is not sufficient
→ Shared email addresses used by more than 5 accounts are excluded from email matching to prevent false positives
→ Same-source pairs are never linked — Lumen will never merge two Operator A records or two Operator B records together
Human-in-the-Loop Review
The cases that need a human. Handled with confidence.
When the matching engine cannot be certain, it doesn't guess. It routes the pair to your MDM analysts — with everything they need to make the right call in under a minute.
Review pair #RQ-004821
Operator A
- Name
- Alex Jordan
- DOB
- 12 Mar 1987
- Mobile
- +44 7911 123 456
- a.jordan@gmail.com
- Postcode
- SW11 4NB
- Product
- PAYM — 50GB plan
78
pts
Operator B
- Name
- Alex Jordan
- DOB
- 12/03/1987
- Mobile
- Not provided
- alex.jordan87@hotmail.com
- Postcode
- SW11 4NB
- Product
- Broadband — 500Mbps
Name + DOB match · 35 pts
Name + Postcode match · 20 pts
Fuzzy name · 10 pts
DOB tiebreaker · 10 pts
No MSISDN match
Email mismatch
7-Day SLA Tracking
Overdue items auto-escalate to supervisors. No review case falls through the cracks.
Separate B2B Queue
Organisation matches route to a dedicated queue. Commercial or legal sign-off can be enforced before linking.
Decision Audit Trail
Every confirm/reject decision is logged with analyst ID, timestamp, and rationale. Immutable and exportable.
Decision as Event
Confirmed and rejected links publish Kafka events instantly. Downstream systems — billing, CRM, loyalty — act immediately.
Segment-Aware Configuration
One platform. Every product line, every customer type.
Matching thresholds and signal weights are configured per segment in the database. No code deployment required. A PAYG customer with limited data needs different matching logic than a named enterprise account.
Pay Monthly (PAYM)
Rich identity signals — name, DOB, MSISDN, email. Standard thresholds apply. High auto-link rates expected.
Default SignalsPay As You Go (PAYG)
Sparser data. No email in many cases. MSISDN weighted higher. Postcode + fuzzy name becomes more important. Thresholds tuned for lower data availability.
Adjusted WeightsBroadband
Strong address signals. PAF-validated postcodes. Fixed-line numbers may differ from mobile. Address hierarchy used as primary corroboration signal alongside name.
Address-PrimaryEnterprise & B2B
Companies House enrichment performed before matching. A single CH number is deterministic. Org hierarchy (parent/child) resolved. Individual contacts migrated and linked back.
CH EnrichmentCompliance & Governance
Built for regulators, not built after them.
Identity consolidation at scale sits directly in the path of GDPR obligations. Lumen treats compliance as a core capability, not a bolt-on. Every action is audited. Every erasure is provable.
Immutable Audit Log
Every match, merge, split, deactivation, and configuration change is written to an append-only audit log. Database permissions prevent UPDATE or DELETE. The record of what happened cannot be altered.
Right to Erasure
A GDPR erasure request against a party ID pseudonymises the golden record across all fields. The structural record is retained for referential integrity; all PII is removed. Downstream services are notified via Kafka.
Subject Access Requests
The SAR endpoint returns a complete view of everything Lumen holds on a given party: golden record, all cross-references, all source system IDs, and the full audit history of every action taken.
Legal Basis Enforcement
Lumen can be configured to require a legal basis before linking records from two source systems. No link is created until legal basis is established — and that establishment is itself audited.
Standards-Based Identity
Output is written directly to TMF632 — the TM Forum open standard for party management. Downstream systems reference a single standards-compliant API. No proprietary identity store. No lock-in.
Correlation ID Tracking
Every API request, batch record, and Kafka event carries a correlation ID. End-to-end traceability from a customer complaint or ICO inquiry back to the exact source record and the exact decision that created the link.
Platform Capabilities
Everything a consolidation programme needs. Nothing it doesn't.
Lumen is a focused tool. It does one thing — identity consolidation — and it does it completely.
Pluggable Source Adapters
CSV, JSONL, or custom formats. Adapters are written after sample data is received — not speculatively. New source systems in future waves require only a new adapter, not a re-architecture.
Pluggable Output Writers
Write to TMF632, Siebel, Amdocs, a flat file, or Kafka events only. The consolidation logic is decoupled from the target — making Lumen usable for any merger programme, not just yours.
Configurable Merge Rules
Per-field golden record rules: Source A wins, Source B wins, most recent, most complete, union (for arrays), or normalised wins. Configured per field, not applied globally.
Idempotent Processing
Every record is fingerprinted with a SHA-256 content hash on ingestion. Re-submitting the same file twice produces no duplicates — safe to retry any batch at any stage.
Dead-Letter Queue
Failed records are never silently dropped. After three attempts, they are routed to a DLQ topic with the failure reason. Manual replay is a single API call.
Prometheus + Grafana Observability
Pre-built dashboards for match rates, queue depth, reconciliation outcomes, ingestion throughput, and error rates. Alerting rules for programme governance teams.
Generic OIDC Security
Works with Azure AD, Okta, Ping, Keycloak, or any standards-compliant IdP. Scope-based access control: read, write, and admin tiers. Only a YAML config change to switch IdP.
Zero-Deployment Configuration
Signal weights, matching thresholds, segment definitions, merge rules, and alert thresholds are all stored in the database. Operational teams can tune the engine without touching code.
Kubernetes-Ready Deployment
Helm charts, Terraform infrastructure-as-code, horizontal pod autoscaling, and rolling deployments. Designed to run on OCI, AWS, or Azure. Zero-downtime from day one.
Your customers are waiting for one version of themselves.
Lumen can be profiling your first data extract within days of engagement. The sooner you start, the sooner every system in your merged estate shares a single, trusted identity.