Roaming file validation for telecom operators: applying operational discipline to TAP3 and NRTRDE.

TAP3 is the GSMA-standardised billing interface between roaming partners, defined in GSMA PRD TD.57. When a subscriber roams on a visited network (VPMN), the visited operator generates call, SMS, and data event records, encodes them in ASN.1 BER as a TAP3 file, and delivers the file to the home network (HPMN) — typically over SFTP — on an agreed cadence. The home network validates the file against the TD.57 specification and the bilateral roaming agreement, and either accepts it or rejects it with a RAP (Returned Account Procedure, TD.32) file.

NRTRDE, defined in GSMA PRD TD.35, is a separate and complementary exchange. NRTRDE files carry roaming usage without the full charging information, but they arrive within four hours of the event so the home network can detect fraud before a compromised SIM has finished running up a bill. As Oracle documents in its billing platform, a TD.35 record is structurally similar to a TAP record but strips out the pricing detail — the actual charging is still exchanged later via TAP. Treat TAP3 as the billing truth and NRTRDE as the fraud-signal truth; both must arrive, both must validate, and neither can be trusted from a script that succeeds silently when a file is missing.

Roaming exchanges fail in ways ordinary SFTP feeds do not, because the counterparty is another operator running its own billing platform on its own schedule. The most common failure modes cluster into a small number of categories. Sequence gaps: TAP3 files carry a per-partner sequence number and a missing or duplicate number is itself a defined error that must generate a RAP response. Encoding failures: an ASN.1 BER file with a zero-byte or truncated element is a TD.57 Fatal error code 53 and rejects the entire batch. Missing mandatory fields: an absent Sender, Recipient, File Sequence Number, or Release Version Number rejects the batch as a Fatal error before any records are read.

Beyond the file level, record-level failures accumulate quietly: syntax errors in individual call events (severe error code 10), timestamps that fall outside the transfer cut-off window, exchange rate references that do not resolve, tax information present without a matching bilateral agreement, or fields that arrive with the wrong TAP release version. For NRTRDE the risk profile is different: a delayed file no longer serves its purpose. If TD.35 files arrive outside the four-hour window, the home network loses the fraud-detection value regardless of whether the content is structurally correct. In both cases, the underlying pattern is the same one Karmon treats as the core of schema-drift detection: a file that arrives is not the same as a file that is correct, and correctness is defined by an external contract you do not control.

Karmon treats every roaming exchange — TAP3 or NRTRDE — as a five-stage workflow rather than a single "receive-and-process" step. The five stages are the same discipline used across Karmon's backend automation and SFTP workflows, adapted to the specific standards of TD.57, TD.35, and TD.32. Each stage has its own failure modes, its own validation gates, and its own audit trail; a file only advances when the previous stage has recorded a durable pass.

The point of separating the stages is that operators need to answer different questions at different layers. Compliance and finance ask "did we accept this file, when, and against which agreement?" Operations asks "which files are late, which are missing, and where in the pipeline did this batch stall?" Fraud teams ask "did the NRTRDE feed from this partner arrive in time to be useful?" One collapsed pipeline that either succeeds or fails cannot answer these questions. Five explicit stages, each observable, can.

The three roaming file types are frequently discussed together, but each answers a different question and carries a different failure cost. The table below summarises the practical differences an operations team needs when scoping monitoring, alerting, and quarantine behaviour.

The operationally important point is that the three formats have different tolerance windows. A TAP3 file that is a day late is an accounting problem, not an emergency; a TAP3 file rejected without a matching RAP is an accounting emergency. An NRTRDE file that is four hours late has already lost most of its value regardless of whether the content is valid. A RAP file that is never returned to the visited network stalls settlement and quietly erodes the roaming agreement. Monitoring has to reflect these different clocks.

Karmon is not proposing to compete with Ericsson, Amdocs, or Nokia on the core roaming clearing stack. Those platforms already ship mature TAP3 decoders, RAP generators, and NRTRDE ingestion. Karmon's work sits in the operational layer around those platforms — the layer where files stop arriving, sequence gaps are noticed late, quarantine folders fill up without anyone owning them, and reconciliation reports are stitched together by hand at month end. That is the same operational-visibility discipline behind Karmon's SFTP automation for business operations and monitoring SFTP automation and data pipeline failures.

In practice that means Karmon builds the observability, retry, quarantine, and reconciliation layer alongside an existing roaming clearing platform, not instead of it. Sequence-number gap detection per partner. Alerting on late NRTRDE files against the four-hour window. RAP-generation audit trails a finance team can query without asking engineering. Schema-drift detection when a partner ships a TAP file at an unexpected release version. The clearing engine keeps decoding and rating; the operational layer makes the whole exchange defensible in front of a regulator, an auditor, or a settlement counterparty.

Operators evaluating this space rarely benefit from building a TAP3 decoder in-house. TD.57 is a moving target, RAP semantics are non-trivial, and the mature clearing platforms have absorbed a decade of edge cases most teams underestimate. The pragmatic split is to buy the clearing engine and build the operational layer: monitoring, quarantine, reconciliation, alerting, and the internal tools your operations team actually opens every morning. That is the same "keep the platform, modernize the operations around it" framing from modernizing legacy software without stopping operations.

What is worth leaving alone is anything the clearing platform already does well and no operator sees. Rating logic, tax computation, and internal ASN.1 grammar rarely benefit from a second implementation. What is worth building is the layer stakeholders complain about: files that arrived but nobody confirmed, RAPs that were generated but nobody tracked, sequence gaps caught a week late, and reconciliation reports assembled by copy-paste. Karmon's engineering services focus specifically on that layer.

Does Karmon build TAP3 decoders or clearing engines? No. Karmon has not shipped a TAP3 or NRTRDE decoder in production and does not compete with clearing platforms like Ericsson, Amdocs, or Nokia on rating and settlement. Karmon builds the operational layer around those platforms: SFTP automation, sequence-number tracking, quarantine, schema-drift detection, reconciliation reporting, and the internal tools operations teams use daily.

What is the difference between TAP3 and NRTRDE? TAP3 (TD.57) is the billing settlement file the visited network sends to the home network on an agreed schedule, with full charging information — it is what the home network is invoiced against. NRTRDE (TD.35) is a lightweight near-real-time feed of roaming usage without charges, delivered within roughly four hours so the home network can detect fraud before a full billing cycle. Both are ASN.1 BER files. TAP3 is the money truth; NRTRDE is the early-warning signal.

What is a RAP file and when is one generated? A RAP (Returned Account Procedure) file, defined in GSMA TD.32, is generated when the home network validates a received TAP3 file and finds errors. A fatal-error RAP returns the entire rejected TAP file when a file-level problem such as invalid ASN.1 encoding or a missing mandatory batch field is detected. A severe-error RAP returns only the rejected records. A missing-error RAP is generated when a TAP file arrives with a sequence number greater than expected, signalling that one or more earlier files are missing.

Why do roaming files fail silently on SFTP? Because a plain SFTP job has no opinion about what should have arrived. A cron script that copies whatever is in the drop folder cannot tell the difference between "no file today" and "the file never came." Roaming exchanges are governed by per-partner sequence numbers, agreed cadences, and freshness windows (four hours for NRTRDE). Silent failure is the default until monitoring is designed to actively expect each file — which is exactly the discipline covered in Karmon's guide to monitoring SFTP automation and data pipeline failures.

Can Karmon integrate its operational layer with an existing clearing platform? Yes. Karmon's standard pattern is to add observability, quarantine, reconciliation, and alerting alongside an existing TAP3/NRTRDE clearing stack rather than replacing it. The clearing engine keeps decoding, rating, and generating RAP files; Karmon builds the layer that answers "did the file arrive, when, in what sequence, and with what outcome" — the questions operations and finance ask on incident calls and audits.

Is this only relevant to large mobile network operators? No. MVNOs, MVNEs, roaming hubs, and settlement providers all handle TAP3, NRTRDE, and RAP files against multiple partners, and the operational-visibility problem scales down cleanly. A hub with fifty partners has fifty independent sequences to track and fifty freshness clocks to respect. The framework in this article applies wherever roaming files are exchanged, regardless of subscriber count.

The right time is before the next incident review, not after. If your team is finding sequence gaps a week late, discovering rejected TAP files in a monthly reconciliation, chasing partners for NRTRDE files that never arrived, or assembling roaming reports by hand at month end, the underlying problem is operational visibility — not the clearing platform. Karmon's Systems Assessment maps the current TAP3, NRTRDE, and RAP flows, identifies the silent-failure surface, and sequences the smallest, safest set of changes that turns the exchange into a monitored workflow.

The output of an assessment is not a rewrite proposal. It is a written map of what already works, what is quietly at risk, and what is worth building next — with an explicit note on what to leave alone. That is the same honest scoping Karmon applies across legacy modernization decisions: modernize only where the risk is real, and preserve the parts that already earn their keep.