DCB risk controls: header integrity and consent binding

For MNOs and MVNE hosts, the weak link in direct carrier billing is often the set of web and signaling edge behaviors around header-based MSISDN detection. Misconfigurations in header enrichment, affiliate flows, and consent handling translate directly into refunds, charge-backs, and regulatory exposure. This article maps the actual DCB request path, pinpoints enforcement points in the network, and shows how to instrument settlement, evidence, and limits to meet EU telco-exemption rules and stricter APAC double-consent regimes.

DCB architecture and attack surface: where fraud actually enters

The reference flow still starts at the packet edge. A subscriber reaches a merchant or affiliate page over WAP billing. Traffic crosses the Gi/SGi/N6 path, where an HTTP proxy can inject the subscriber identifier only for whitelisted FQDNs. In 4G, that path is normally tied to the PGW and policy enforcement. In 5G, it moves closer to the UPF and service chain. If the subscriber is off-net, roaming, Wi-Fi attached, or blocked by policy, the flow usually falls back to OTP or PIN confirmation via MT SMS. Legacy PSMS flows now carry less revenue share in many markets, but they still create complaint volume because evidence chains are weaker and affiliate attribution is often poor.

The commercial chain is longer than the network path. User, affiliate, merchant, aggregator, MNO gateway, OCS and BSS all see different parts of the event. Fraud often enters before the MNO sees a consent token. Affiliate clickjacking, auto-redirects, malware-driven silent subscriptions, reverse-proxy header spoofing off-net, bot farms abusing one-click flows, and SIM-swap timing all exploit that split. The downstream CDR may look complete while the consent page was misleading or never visible.

The instrumentation points are therefore specific. Header injection should be allowed only for registered domains. MSISDN headers should be HMAC-signed with merchant-specific secrets and short validity. Server-side consent verification should be exposed through an MNO DCB gateway or NEF interface, not accepted only as an aggregator callback. PCF rules should steer DCB-tagged FQDNs through enrichment, bot filtering, and logging. The same event key must correlate request ID, injected header, IP, User-Agent, consent timestamp, OTP message ID, merchant metadata, and subscriber cap state.

Enrichment point

HTTP proxy on Gi/SGi/N6 path tied to PGW/UPF, injecting MSISDN headers for whitelisted FQDNs

Consent UI host

Aggregator-controlled domain or MNO-hosted page; must return a server-side token to MNO/NEF

Risk decision

MNO DCB gateway or external fraud engine; evaluates token, SIM-swap age, RFM, device/IP reputation

Monetisation event

OCS real-time charge; BSS receives DCB CDR for settlement posting

Dispute artefacts

HTTP logs, OTP MT logs, consent token record, merchant metadata, subscriber caps state

Enforcing consent in the network path: token binding, SIM-swap, and policy control

Consent should be verified inside the MNO-controlled path and bound to subscriber context. Merchant callbacks are useful inputs, not authorities. A practical baseline is double confirmation: an in-session PIN or MT confirmation generates a nonce, the server stores only its hash, and the token expires quickly. The merchant or aggregator then calls the MNO DCB API with the token, merchant ID, FQDN, amount, tax, and currency. Charging is rejected if any element differs from the stored consent record.

Binding should use the subscriber and network context observed at the edge. Store the token against IMSI, MSISDN, observed IP, User-Agent, APN, merchant, FQDN, and price payload. Accept billing only within the token TTL and only for the exact merchant and amount. If the callback arrives from a different origin, or if the enriched subscriber context cannot be reproduced, the event should move to OTP or fail closed.

Header integrity is a separate control. X-MSISDN and related enrichment headers should be signed with HMAC, using per-merchant keys and rotation windows short enough to limit replay value. Referer and origin checks are not sufficient, but they catch basic proxy abuse and misrouted affiliate traffic. Recent HLR events, number portability changes, or IMSI changes should also feed the risk decision. A port-in or SIM-swap inside the configured cooling period should force OTP even when the user has a prior subscription with the merchant.

Policy control closes the loop. PCF rules should identify DCB FQDNs and steer them through the enrichment proxy, risk engine, and rate limiter. Unregistered domains should not receive enrichment. Rate limits should apply per IMSI, MSISDN, IP range, merchant, and affiliate ID. The limit model must distinguish failed consent attempts from successful billing attempts; otherwise bot farms can stay below charge thresholds while still probing the flow.

Settlement, refunds, and charge-back exposure: building the evidence loop

Charge-back performance improves when posting, evidence capture, and refund policy sit in the event stream. The OCS charge should occur only after server-side consent verification. At that point, the platform should write a compact evidence blob beside the DCB CDR primary key: token hash, OTP identifiers, header signature status, IP, User-Agent, merchant catalog ID, price, tax, currency, and screenshot or HTML hash. The evidence blob does not need to carry raw page content if hashes and immutable storage links are retained.

Exposure should be managed as a financial position, not a monthly reconciliation surprise. Net exposure equals unbilled DCB events plus receivables, less rolling reserves and held payouts. Per-merchant limits should throttle new charges when refund ratios, complaint rates, failed-consent attempts, or SIM-swap-at-time-of-charge indicators move outside tolerance. The risk engine should be able to hold settlement for a merchant without blocking the subscriber refund workflow.

Refund handling needs standardized reason codes: no consent, minor, misleading UX, technical fault, duplicate charge, and customer goodwill. Those codes should map to refund SLAs and debit-note rules. When the MNO raises a debit note to the aggregator or merchant, the evidence bundle should be complete enough to avoid a second dispute cycle. Batch windows should align with reversal cutoffs; otherwise the operator refunds the subscriber while the merchant payout has already cleared.

A recent anonymized case shows the commercial effect. Tier-2 MNO, EMEA, ~18M subscribers introduced HMAC-signed headers, domain pinning, and OTP-on-SIM-change across its main DCB corridors. Affiliate-driven refunds fell by ~35%, and DCB contribution margin improved by ~200 bps over two quarters. The largest gain came from rejecting charges before OCS posting, not from improving post-factum dispute handling.

Regulatory alignment: caps, consent artefacts, and merchant due diligence

Regulatory alignment works only when the controls are configurable at market level. In the EU, the operating model should remain inside the PSD2 telecom exemption scope, with digital content and permitted charity use cases separated from general commerce. Per-transaction and monthly caps should apply per MSISDN and should be enforced before charging, not reported after settlement. Telco-specific controls such as OTP, token binding, SIM-swap cooling periods, and merchant domain pinning form the practical substitute for payments-style SCA where the exemption applies.

APAC control sets are often stricter in practice. Many markets require explicit price display, tax presentation, subscription frequency, and double confirmation before the first charge and before recurring renewal. Several impose complaint-rate thresholds, merchant blacklists, or mandatory affiliate shutdowns. The DCB gateway should therefore treat caps, confirmation method, retention period, and suspension thresholds as configuration, not code branches.

Merchant onboarding is part of fraud control. Corporate KYC, directors, bank account, registered domains, shortcodes, pricing catalog, customer-care contact, and affiliate-program disclosures should be captured before live traffic. Header enrichment must be prohibited on unregistered FQDNs. A merchant that changes landing domains or affiliate networks without approval should lose enrichment until the new path is reviewed.

Data minimisation also matters. Raw MSISDN should not pass to merchants off-net. Use pseudonymous tokens and resolve subscriber identity only inside the MNO or approved gateway. Consent artefacts, header signatures, OTP logs, complaint IDs, settlement references, and screenshot hashes should be retained for the required market period, then aged out under group data protection policy.

Spend caps to enforce

Per-tx and monthly caps per MSISDN; market-specific values via configuration

Consent artefacts

OTP MT IDs, server-side token hash, header signature, timestamp, merchant/FQDN, price, tax, currency

Merchant KYC fields

Legal entity, directors, bank account, domain/shortcode list, complaint contact, affiliate program details

Operational KPIs

Refund ratio, complaints per 1,000 tx, charge-back rate, SIM-swap-at-time-of-charge, average time-to-refund

Retention policy

Market-specific; align logs and screenshot hashes with regulator requirements and group data protection policy

DCB can remain profitable when identity, consent, and settlement stay under operator control with enforceable, auditable limits. Build controls at the network edge, price exposure into merchant settlement, and keep artefacts ready for regulators. Only then should the operator expand merchant coverage with confidence.