Borrowed Authority: Governing the External Lists Your Integrations Treat as Truth

Most integration defects are not caused by badly written code. They are caused by a confident assumption about a list that someone else maintains. A postcode that no longer validates, a VAT rate that changes at a boundary date, a company number that is well formed but no longer active, or a currency whose minor units are misunderstood can all produce the same result: an interface that appears to work while making the wrong decision.

Reference data is rarely glamorous. It sits behind address validation, tax calculation, supplier onboarding, payment routing and reconciliation. Because it looks like a simple lookup, it is often treated as a constant. In practice it is an external dependency with a release cycle, an owner, a licence and a failure mode. The integration team may not possess the list, but it owns the consequences of using it.

The quiet authority of a lookup

Consider the ordinary postcode field. It is used to validate an address, route a delivery, segment a customer base or match records across systems. The Royal Mail Postcode Address File and the ONS Postcode Directory are not interchangeable, and neither is a static copy held in a local table. Each has coverage, licensing and update characteristics that affect what the integration can safely conclude.

The same pattern appears elsewhere. HMRC publishes VAT rates and thresholds with effective dates. Companies House holds registration numbers and status information that can change after onboarding. ISO 4217 defines currency codes and minor units, but a payment system may still apply rounding rules that are local to the transaction. None of these sources is under the organisation's control. All of them can change without a corresponding change to the integration.

That is the central point: a reference list is an interface. It has a provider, a consumer, a format and a change history. If it is not governed as such, the integration is relying on borrowed authority without a contract.

Inventory the lists, not just the systems

A useful first step is a reference data dependency register. This should not become an enterprise data catalogue by stealth. It needs to capture only what is necessary to operate and assure the interface: the source of the list, the internal steward, the refresh cadence, the delivery format, the identifiers used, the coverage and licence terms, and the systems that consume it.

It is important to distinguish primary sources from intermediaries. A cleansing tool may supply postcode data derived from PAF, while a finance platform may embed HMRC rates in its own configuration. The integration may consume the intermediary, but the authority still originates elsewhere. Record both, because the failure path will follow the chain.

For each entry, note where the data is used for validation, routing, calculation or reconciliation. A postcode used to check that an address is plausible is a different dependency from a postcode used to assign a delivery route. A VAT rate used to display an estimate is different from one used to post a journal. The register should expose those differences, because they determine how much protection the interface needs.

Ownership without possession

The organisation cannot own the Postcode Address File or the VAT rate schedule. It can, however, own its use of them. That means naming an accountable internal owner for each dependency, even when the source is external. The owner does not maintain the list; they maintain the integration's behaviour against it.

Ownership should include a named contact or subscription for change notices, a review of published release schedules, and a defined response when a change is announced. Where formal notices are unreliable, the integration should carry its own observation. Synthetic checks can validate a known sample of postcodes, confirm that a VAT lookup returns an effective-dated rate, or verify that a company number enquiry still distinguishes between formatted and active records.

Change alerts should be routed to the team that can act on them, not merely to a shared mailbox. A monthly reminder that a list has updated is not the same as an alert that a consumed field has changed shape or that a new rate applies from a specific date. The register should state which changes are material to which interfaces.

Design for unknown, invalid and effective

Many integrations collapse too many states into a single failure. A postcode that is absent from a local copy may be new, retired, mistyped or simply outside the licensed coverage. A company number that fails a pattern check may be invalid, while one that passes may belong to a dissolved entity. These distinctions matter.

Interfaces should preserve the raw input and record the reference dataset version used to reach a decision. Validation should distinguish between unknown and invalid. Where a lookup is unavailable, the interface should have an explicit fallback: queue and retry, accept with a flag for later review, or reject. The choice should be based on the transaction, not on the convenience of the developer.

Effective dating is essential for tax and financial reference data. A VAT rate should not be overwritten in place if historical transactions must remain explainable. The integration should select the rate that applies to the transaction date and retain evidence of that selection. Currency handling should be equally explicit about minor units and rounding, rather than assuming that every code behaves like sterling.

Postcodes deserve particular caution. They are not a stable identity for a property, and a successful format check does not confirm that an address exists. Where address matching matters, the integration should treat the postcode as one signal among several and avoid silent substitution of one record for another.

Make the dependency visible in operations

A governed dependency leaves evidence. Logs should show which reference dataset or service was consulted, which version or effective date was applied, and what decision followed. Reconciliation should be able to explain why a transaction was accepted, held or rejected because of reference data.

Runbook entries should include the source, the escalation route and the expected behaviour when the source is late or unavailable. Test plans should include a planned update: a new postcode, a rate change, a company status change or a currency adjustment. If the integration has never been exercised against a changed list, it is not ready for production.

The final discipline is architectural rather than administrative. Reference data belongs in the integration design as a dependency with a lifecycle. The organisation may borrow the authority, but it must own the decision, the evidence and the safe failure. That is what separates a working interface from one that merely works until the next list is published.