Swift's deferral turns the address cutover date into data the service has to version

Field level lineage, as the dev.to write-up defines it, attaches four things to every outgoing address component: the source revision it came from, the payment party it belongs to, the transformation that produced it, and the rules that approved its use ^[6]. Without those links, an investigator cannot separate customer supplied data from a parser's guess, and cannot reproduce the decision once the customer record changes ^[8].

The first of the four is where most systems fail. A pointer to the latest customer profile does not qualify ^[9]. If the customer edits an address tomorrow, an investigation into yesterday's payment still needs the version used yesterday, so the reference needs a stable record identifier and an immutable revision ^[9]. Two timestamps go with it: the source's effective time, where it is known, and the time your system observed the value ^[10]. A late correction can push those far apart ^[10].

The runbook keeps the original representation in a controlled evidence store, and has the operational event carry an opaque reference plus an integrity digest instead of a second copy of the address ^[11]. The write-up is careful about what the digest buys. It shows whether bytes changed, and it does not show that the address was accurate, lawfully collected, or attached to the right person ^[12]. Retention, access and retrieval get defined together, because a lineage identifier that resolves to an expired object is no help during an investigation ^[13].

The deferral lands in code, not only in plans. A rule package, its approval status and its activation date are three separate facts, and a migration service that hardcodes a date lifted from an old presentation has already lost one kind of provenance ^[14][15]. The post's answer is to store the document reference, the retrieval date, the applicable scheme and the activation decision next to the rules, and to keep improving address capture while the external timetable moves ^[16].

Each gate emits one linked record, and each gate permits a stop ^[17]. Missing country evidence should raise a visible exception with an owner, and that exception returns through validation after correction ^[18][19].

The gates are an internal acceptance contract and a proposed engineering design, not a Swift certification procedure, and the post says so ^[20]. For the cost to be worth paying, a few things have to hold in your flow. Addresses have to arrive through several doors with different owners, such as customer onboarding, beneficiary maintenance, ERP imports, treasury files and service APIs ^[21]. What the system stores has to differ from what the upstream team believes it stores ^[22]. And someone has to ask, months later, which value reached which message field, because a database backfill count cannot answer that ^[23]. The procurement form of the same question, in the post's framing, is which team owns the evidence across data ownership, payment orchestration and integration, including the interfaces outside a supplier's own codebase ^[24].

Swift promised an update by December at the latest ^[3]. Counted from the write-up's September 24, 2026 status check, that is 68 days, about ten weeks ^[2][1]. The Bank of England's implementation page expects a twelve-month deferral into November 2027, including removal of unstructured address fields, subject to confirmation and wider validation ^[5].