The SWIFT Deadline Moved. Why Beneficiary Town and Country Still Matter.

SWIFT has extended the timetable for removing unstructured addresses from its payment messages. That removes one immediate cutover date. It does not remove the underlying question for maritime companies: where do the beneficiary’s town and country come from, and can those details travel reliably from the crew system into the payment instruction?

For much of 2026, the message seemed simple.

From 14 November, fully unstructured postal addresses would no longer be supported in SWIFT’s CBPR+ payment messages. Town and country would have to appear in designated fields at a minimum, with fully structured or hybrid addresses used instead.

Then, on 27 August, SWIFT accepted an industry request to extend the migration.

The old deadline no longer tells the whole story.

That might sound like a reason for corporate payment teams to put address work back into the drawer marked “later”. It is not.

The extension changes the timetable. It does not change where creditor—or beneficiary—address information originates. Nor does it remove the operational value of knowing whether the town and country needed by a bank or payment channel are stored clearly, mapped correctly and available when a payment is prepared.

For companies making crew allotment payments, that work begins well before a SWIFT message exists.

“What exactly did SWIFT change?”

SWIFT did not announce a new universal deadline on 27 August.

It announced what it called a controlled extension of Standards Release 2026. For payments, SWIFT said it would defer all planned changes. It would consult banks, central banks, payment-market infrastructures, market-practice groups and corporates on the structured-address timing and approach, and provide an update by December 2026 at the latest.

SWIFT also encouraged financial institutions and domestic payment infrastructures to continue progressing their structured-address work. Institutions that have already upgraded can use structured addresses today.

So there are two facts to hold together:

• the November 2026 SWIFT payments cutover has been deferred; and
• the industry direction towards structured and hybrid address data remains.

Takeaway: SWIFT removed the immediate payment cutover date; it did not reverse the move towards structured beneficiary address data.

“Is there now one replacement date we can put in the project plan?”

No—not yet, and not necessarily across every payment route.

SWIFT said it would provide a further update by December. Other payment infrastructures have made or are making their own decisions.

The Bank of England delayed its entire November 2026 RTGS standards release, including the messaging standards for CHAPS payments.

On 9 September, the European Payments Council decided to delay the November end date for unstructured addresses under all five EPC payment-scheme rulebooks. Its Payment Scheme Management Board will reconvene in October to set a new end date.

The Federal Reserve Banks’ current Fedwire timetable says the relevant release was rescheduled from November 2026 to November 2027. The exact November 2027 date is still to be announced.

These examples do not need to become a corporate payment team’s new collection of standards trivia.

They illustrate a practical point: “the structured-address deadline” is not one date that can safely be inferred for every currency, bank, rail or payment channel.

A maritime company may pay allotments through different banks, in different currencies and through different file or portal arrangements. The useful question is therefore not only, “What did SWIFT announce?” It is also, “What will each of our banks and payment providers require, through each channel we use, and when?”

Takeaway: Treat address readiness as a bank-, rail- and channel-specific question—not as one global date copied from a headline.

“Why were town and country singled out in the first place?”

An address written as several lines of free text may be readable to a person. It is harder for payment systems to interpret consistently.

Is the place name on line two a town, district, province or country? Is the country written as a name or a code? Has a field been shortened to fit an older format? Can the next institution in the payment chain identify the same components without guessing?

Structured data gives particular pieces of information a defined place. Under SWIFT’s pre-extension guidance for the planned change, Town Name and Country were the minimum structured elements for a fully structured or hybrid postal address.

SWIFT’s address guidance explains the intended benefits: better identification of parties, improved straight-through processing, fewer repairs and manual interventions, greater transparency, and more effective sanctions screening and AML controls.

None of those benefits turns an address into proof that a payment is safe or legally permitted.

Town and country are useful because they give systems and reviewers more specific context. They can help distinguish people with similar names, identify inconsistent information and support investigation when a possible match or geographic concern appears.

Takeaway: Town and country matter because they convert part of a human-readable address into information that payment and control systems can interpret consistently.

“What does this have to do with a crew allotment?”

SWIFT does not reach into a crew-management system and create beneficiary data.

The information begins upstream.

A crew member nominates an account for an allotment. The company stores a combination of beneficiary and banking information. Depending on the system and process, that may include:

• the beneficiary name as held for the bank account;
• relationship to the crew member or payment-purpose context;
• beneficiary country and postal or residential address;
• currency;
• receiving-bank and account details;
• an optional intermediary bank; and
• contact information.

When the account is selected for payment, some of that information is mapped into a payment draft, bank file, portal entry or API instruction. The bank then maps or uses the information required for the relevant payment route.

The operational chain is therefore something like:

Not every crew payment has a cross-border leg. Not every allotment uses SWIFT. But where a payment eventually enters a cross-border banking chain, the quality of the downstream message depends partly on information created and maintained much earlier.

Takeaway: The bank may create or transmit the payment message, but the beneficiary address often originates in the company’s own crew-payment records.

“Don’t crew-management systems already hold the address?”

Often, yes.

In crew-management systems Roy has worked with, beneficiary residential or postal address information is commonly retained alongside the beneficiary’s banking information. Country is usually a separate field. Bank details, optional intermediary-bank details and beneficiary details may also be presented as distinct sections.

That is a useful starting point.

The complication is that town may not be a separate field. It may be embedded in an address containing a city, state, province, county, district, postal code and other free text. A person reading the screen may understand the address immediately. A mapping that needs a definite Town Name value may not.

There are other location fields nearby, too:

• beneficiary country;
• beneficiary nationality, where retained;
• receiving-bank country;
• branch city or address;
• intermediary-bank country and address; and
• the country associated with an account or routing identifier.

These fields answer different questions. Substituting the bank’s city for the beneficiary’s town would create a syntactically populated field with the wrong meaning—which is the data equivalent of confidently boarding the wrong vessel.

The readiness exercise is not merely “Do we have an address?” It is:

• can we identify the beneficiary town and country without guesswork;
• are those values stored or derivable under a defined rule;
• can users correct them without corrupting the original address;
• and will the right values survive every mapping to the bank?

Takeaway: An address can exist in the crew system while the beneficiary town needed downstream remains buried, ambiguous or mapped to the wrong location field.

“If the bank file does not ask for town today, why should we care?”

Because the bank file is one implementation point, not the complete source of truth.

Maritime companies do not all send one standard bank file. Depending on the bank and region, they may use a standard or variant of SEPA, a bank-defined text or CSV file, an Excel template, a portal, an encrypted file or another proprietary arrangement.

Some formats ask for more beneficiary detail than others. Some banks may enrich, transform or validate customer data in their own channels. Requirements can change at different times.

This variation is precisely why a company should not redesign its source data around one current spreadsheet column.

A sensible readiness review asks:

1. Which payment routes and bank channels do we actually use?
2. Which beneficiary address fields does each one accept or require today?
3. What future changes has each bank communicated?
4. Where are town and country held in our source system?
5. What transformation occurs between the source record and the submitted instruction?
6. Can we test the output with the bank before a mandatory change takes effect?

SWIFT’s corporate guidance has made the upstream expectation unusually visible: corporates source creditor address information through their own channels, retain it in an ERP or treasury application and provide it to the bank at payment initiation. The exact channel can differ; the need for usable source data remains.

Takeaway: A company’s source data should be capable of serving changing bank and channel requirements, rather than being limited by the least demanding file it sends today.

“Is this really a sanctions-screening issue?”

It is partly a screening and investigation issue. It is not only that.

Structured town and country information can help payment systems identify parties more consistently and reduce false positives. For a human reviewer, location may help distinguish a beneficiary from a similarly named person on a sanctions list.

Location can also matter in its own right. OFAC explains that sanctions can take different forms, including broad prohibitions involving a geographic region. Its Crimea advisory, for example, described Executive Order 13685 as prohibiting virtually all direct and indirect transactions by US persons or within the United States to or from Crimea, unless authorised or exempt.

That does not mean every person with an address in a particular place is automatically a listed person. Nor does an address field by itself establish the legal treatment of a payment. Applicable sanctions, authorisations, parties, ownership, payment route and jurisdiction still require proper analysis.

The more modest point is that location information can be relevant to a decision even where a name produces no obvious match. If the beneficiary address changes materially—or if the company discovers that a country or town was wrong or missing—that may deserve review under the company’s policy.

The same data also supports payment repair, fraud controls, record quality and straight-through processing.

Takeaway: Beneficiary location is useful control context, but it is neither a sanctions verdict nor a substitute for reviewing the complete payment.

“Has the extension reduced the urgency?”

It has reduced one kind of urgency: the risk of preparing against a SWIFT payment cutover that was expected in November 2026.

That is good. Project plans should change when the governing timetable changes.

But there is a difference between cancelling a rushed implementation and abandoning the discovery work.

The extension creates time to answer questions that should have been answered before fields were added to a file:

• How many beneficiary records contain a usable country?
• How often is town identifiable only inside free text?
• Are the beneficiary and bank locations clearly distinguished?
• Which active payment accounts have incomplete or obviously inconsistent addresses?
• Which bank-file mappings drop information already present in the source system?
• Which banks and payment providers have supplied updated specifications?
• Which destinations, currencies and rails are affected first?
• Who owns correction of beneficiary information, and what approval is needed?

This work is largely reversible and useful. It improves understanding without forcing the company to guess a final technical design before SWIFT and other infrastructures finish setting their dates.

Takeaway: Use the extension to replace deadline-driven guesswork with source-data discovery, bank engagement and controlled testing.

“What should a maritime company do next?”

Start with its real payment estate rather than a generic ISO 20022 project plan.

1. Inventory the routes

List the banks, payment providers, currencies, rails and submission channels used for crew allotments and other relevant payments.

2. Ask each provider for the current position

Obtain the applicable specifications, planned dates, validation rules and testing arrangements. Ask whether town and country are required for the creditor or beneficiary, how they must be represented, and what happens when the data is missing.

3. Inspect the source records

Measure—not guess—how beneficiary country and address are stored. Identify records where town is absent, embedded in free text or confused with bank location.

4. Trace the mapping

Follow a sample from the crew-management record through the payment-account master, payment draft and bank submission. Confirm which values survive and where transformations occur.

5. Define correction and review ownership

Decide who may request updated information, who approves a material beneficiary change and whether the account can be used while an issue remains unresolved.

6. Preserve the reason

If a town or country is corrected, record what changed, who approved it and which current payment instructions are affected. Better data loses some of its value if nobody can later explain how it became better.

Takeaway: The immediate deliverable is a verified map from beneficiary source data to each payment channel, with owners for gaps and changes.

“Where could CrewPayScan fit?”

CrewPayScan is not intended to replace the company’s crew-management system, bank file or payment provider.

A company may be able to identify missing town or country information directly in its crew-management system by using an existing report or a controlled database query. It should not need to send the same data to another service merely to discover that a field is blank.

CrewPayScan’s more relevant role begins when beneficiary and bank information is used in a current screening and payment-control decision.

Structured beneficiary country and town can improve the context available for possible-match review. A material address change can also become an event that the company’s chosen policy considers, rather than silently flowing into the next payment.

In practical terms, CrewPayScan could help a company:

• screen beneficiary and relevant bank information connected to current payments;
• use available town and country information as context when investigating a possible match;
• distinguish a material address or account change from an unchanged recurring instruction;
• preserve earlier candidates, human resolutions and the information that supported them;
• bring insufficient or changed location context to a reviewer’s attention when it affects a current check;
• route an affected payment instruction for review before bank-file submission where the workflow permits; and
• retain evidence showing which data was checked and what the company decided.

The bank and payment provider would continue to apply their own specifications and controls. The company would continue to decide what information it is appropriate to collect and what its policy requires.

CrewPayScan’s value here is not a second report of empty source-system fields. It is to help turn the beneficiary and bank data attached to a current payment into usable screening context, a controlled review event and an explainable decision history.

Takeaway: Better address data becomes operationally valuable when it strengthens a current screening decision, change review and evidence trail—not when it is merely copied elsewhere and checked for blanks.

The useful deadline is the one inside the company

SWIFT will provide another timing update. Payment infrastructures and banks will continue to publish specifications. Those dates matter.

But a company does not need to wait for the next announcement to learn whether it can answer a simpler set of questions:

• Do we know the beneficiary’s town and country for the payment accounts we use?
• Are those values distinct from the bank’s location and other country fields?
• Can they travel correctly into each bank channel?
• Do we know which records changed and who approved the correction?
• Can the same information support screening and investigation before release?

If those answers are unclear, the extension has not removed the work. It has provided a better opportunity to do it without a cutover clock dictating every decision.

The most useful response to a moved deadline is not to stop preparing. It is to stop guessing: trace the data, speak to the banks, test the mappings and make the beneficiary information useful before the next date becomes urgent.

Payment-message requirements vary by rail, bank, channel and implementation date. Sanctions obligations vary by jurisdiction, parties and transaction. This article discusses operational data and control design and does not constitute legal advice.