Provider data needs a receipt

The number arrived. What arrived with it?

Consider a valuation arriving in a client record. It looks precise, occupies the correct field and appears on the next report. The missing detail is less photogenic: what date does that value describe?

Successful delivery of a number is only one part of a successful transfer. The receiving process also needs enough context to decide whether that number is suitable for its next use. This makes an apparently straightforward provider integration a test of the firm's information handling.

Our recommendation is to treat incoming provider information as an evidence package rather than a bare update. Think of the surrounding context as its receipt.

Define the receipt

For each important value, preserve the source, relevant account or policy identifier, effective date, receipt time and any transformation performed. Where the source supplies a status or limitation, carry that too.

The effective date and receipt time answer different questions. One explains when the information applied. The other explains when the firm knew it. Merging them into one timestamp makes late-arriving information look newly current.

The Government Data Quality Framework separates timeliness from other quality dimensions. Its distinctions help frame the problem, although it is not a provider-data specification or an advice-sector rulebook.

There is also a personal-data reason to preserve context. The ICO's accuracy guidance says the source and status of personal data should be clear. It distinguishes a historical fact from an assertion about the present. Applied to a provider feed, that strengthens the case for retaining dated observations instead of overwriting them into an apparently timeless fact.

A receipt in practice

Take a fictional policy record. A file received on 12 September contains a value effective on 31 August. A second file arrives on 13 September, but its value is effective on 31 July. Choosing the last received value would move the client's visible valuation backwards in time while making the screen appear newly refreshed.

The proposed receipt therefore carries two separate dates, the policy identifier, the source document or response reference, the original field name and the mapped meaning. Add the mapping version and any source-supplied limitation. The display can then show an August valuation received in September, rather than implying that the policy was valued on the day of import.

Record the July observation too if it is needed for the firm's legitimate purpose and retention policy, but do not silently promote it into the current field. Send the conflict through the rule governing that workflow. An operator may discover a correction, a duplicate historical file or a misunderstood field. The receipt makes those possibilities investigable.

A compact acceptance script follows from the example. Deliver the August record, then the older July record, then repeat the August delivery. Confirm that the relevant workflow still selects the intended observation, that the repetition does not create duplicate work and that the operator can open the source evidence. Finally, remove the effective date and check that the system shows uncertainty rather than borrowing the receipt date.

Do not normalise away meaning

Suppose two incoming files use different labels for a monetary amount. Before mapping both into a common valuation field, establish whether they describe equivalent things. A consistent label cannot repair a semantic mismatch.

Document the mapping in plain language and attach a version to it. If the interpretation changes later, the firm should be able to identify which historical records used the previous mapping and decide whether any downstream work needs review.

This is where provider-data projects can become more demanding than the original integration estimate. Transport asks whether a file can be received. Interpretation asks what each field means in the receiving firm's process.

Use freshness by purpose

Set freshness rules around the intended use, with the relevant business owner. A historical analysis and an imminent client action may need different information. Avoid labelling data simply fresh or stale across every workflow.

Where required information is unavailable, show that state explicitly. An empty field, an old value and a failed request are different conditions. Collapsing them into missing prevents the operator from selecting the right response.

A useful exception screen answers three questions: what could not be obtained, what work does it affect and who will resolve it? Include the last successful retrieval and the latest failure so staff can investigate without reconstructing the entire history.

Reconcile before trusting the feed

Test a small, varied set of records against source evidence. Include revised values, missing identifiers, duplicated deliveries and delayed information. Verify both the values and the context around them.

Monitor changes in coverage and exception types after release. A feed that keeps returning successful responses can still stop supplying a field your process depends on. Technical availability and business usefulness deserve separate checks.

For rollout, keep a mapping register with a named business approver, a technical owner and representative source examples. When a field changes, compare the new interpretation against those examples before switching live records. Give the operator a way to identify affected cases if a faulty interpretation has already travelled downstream. Recovery should target the records touched by the change, not require a blind recheck of the entire client base.

Agree who can approve a mapping change and what review follows it. That decision should exist before a supplier changes a format on a busy morning.

The buying question is sharper than whether a tool connects to a provider. Ask it to show the receipt for a value already used in a client workflow. If it cannot, the integration has moved the information further than it has moved your ability to trust it.