The BSA travel rule for wires still names a 1990s Fedwire format

The BSA travel rule for wires, 31 CFR 1010.410(f), requires a US bank sending a wire of $3,000 or more to include the originator's name, address and account number (if the payment comes from an account), the amount, the date, the beneficiary's bank, the beneficiary details it received and its own identity, and an intermediary to pass them on. Its text still carries an exception written for the mid-1990s: the originator's address is not required on "a transmittal order through Fedwire until such time as the bank that sends the order to the Federal Reserve Bank completes its conversion to the expanded Fedwire format" (31 CFR 1010.410(f)(1)(ii)). That conversion was a 1990s project that FinCEN said in 1998 was "Generally" required to be completed "by the end of 1997", and Fedwire moved again, to ISO 20022, in July 2025. Botminds' Funds Transfer Recordkeeping & Travel Rule reads every Fedwire and SWIFT wire against the full list of fields and treats a missing originator address on a Fedwire as a gap, because nothing we found says the old exception still covers anyone.

Does the travel rule apply to Fedwire?

Yes. The travel rule applies to every transmittal order of $3,000 or more sent by a US transmittor's or intermediary institution, whatever system carries it, and Fedwire is the largest: 217,296,700 transfers in 2025, worth about $1.148 quadrillion, some 869,187 a day (Fedwire Funds Service annual statistics). Fedwire is also the only payment system the rule names, and it names it only to carve out relief while banks upgraded their message format.

The FFIEC BSA/AML Examination Manual, which examiners work from, lists the travel rule items for a transmittor's financial institution as name and account, "Address of the transmittor", amount, date, the recipient's institution, the recipient items received, and the sender's identity, with no Fedwire caveat at all (FFIEC manual, Funds Transfers Recordkeeping). The exception lives in the regulation's text, not in the way the rule is examined.

What is the expanded Fedwire format?

It was the larger Fedwire message format the Federal Reserve introduced in the 1990s, with room for the originator and beneficiary information the new rules required. FinCEN recorded in 1998 that "The expanded Fedwire format was announced by the Federal Reserve Board on the same day as the Joint Rule and the Travel Rule", January 3, 1995 (FinCEN Issuance 98-1). The old format simply did not fit the data.

Until all banks convert to the expanded Fedwire format, there will not always be enough space to include in a transmittal order all of the information required by the rule.

FinCEN, 61 FR 14383 (April 1, 1996)

That sentence, from the 1996 amendment, is the whole reason the clause exists. The banking industry raised the problem after the comment period closed, and FinCEN accepted it: industry representatives had assured it "that the expanded Fedwire format, scheduled to be adopted industry-wide by January 1, 1998, will allow all information required by paragraph (g) to be sent and received," and requiring an interim system until then would have cost "considerable resources" (61 FR 14383). So the 1996 rule added a safe harbor and delayed the amended travel rule's effective date to May 28, 1996.

Where the 1990s clause still sits in today's text

The clause appears in six places across the two funds transfer sections, each tied to the same condition: the sending bank's conversion to the expanded Fedwire format. None has been removed.

The safe harbor is the most interesting of the six, because it describes a different idea of compliance. Before conversion, a sending bank was "deemed to be in compliance" if it included the amount, the date, the recipient's institution and the recipient items received, and then supplied the originator's name, address and its own identity "within a reasonable time" when another bank in the chain asked for them for a law enforcement request or its own BSA compliance. Information obtained that way then counted as if it had travelled with the order (31 CFR 1010.410(f)(3); the travel rule paragraph by paragraph quotes it). It was a pull model, built for a message that could not carry everything.

Is the originator address required on a Fedwire?

Read on its own terms, yes, for any bank that converted to the expanded format, and FinCEN expected that to be every bank by the end of the 1990s. The 1998 issuance put it plainly: the safe harbor "only applies prior to the date that an institution completes its conversion to the expanded message format of the Fedwire funds transfer system. Generally, that transformation is required to be completed by the end of 1997" (FinCEN Issuance 98-1). Some banks could not start full compliance on conversion day because of "delays in completing related programming tasks, for example the linking of inbound and outbound message systems", so FinCEN extended the safe harbor to orders sent before April 1, 1998.

We found no later statement by FinCEN or the banking agencies that the exception still applies to any bank, and the examination manual lists the address without it. A bank that leaves the originator's address off a Fedwire today, relying on a clause whose condition was meant to lapse in 1997 or 1998, would be making an argument no regulator has endorsed. The sensible reading is the one the solution applies: the clause is history, and the address goes in.

When was the travel rule written?

On January 3, 1995, as 31 CFR 103.33(g), the same day Treasury and the Federal Reserve issued the joint recordkeeping rule and the Fed announced the expanded Fedwire format. It was amended on April 1, 1996, taking effect May 28, 1996, with the Fedwire safe harbor; relaxed again by FinCEN's conditional exceptions of January 1998; and now sits at 31 CFR 1010.410(f), renumbered in the 2010 reorganization of FinCEN's rules (75 FR 65812) and last amended in 2016 (81 FR 76864).

The 1998 issuance also shows how the industry actually complied in those years. A working group of large banks and broker-dealers told FinCEN that their customer information files often held "a post office box mailing address rather than the customer's street address, or (somewhat less frequently) a nominee or 'special' or coded name", and that reprogramming them would divert resources from "correction of the world-wide 'Year 2000' problem." FinCEN let them send the file's name and address with "a question mark symbol ('?')" after any designation other than a true name, an exception set to expire on May 31, 1999.

Has the travel rule been updated?

Its numbering and parts of its text have; its Fedwire clauses have not. The rule moved from 103.33(g) to 1010.410(f), and the eCFR shows amendments in 2010 and 2016, yet the conversion language from 1996 is still in (f)(1)(ii), (f)(2)(ii), the footnotes and (f)(3). The one serious attempt to change the travel rule's substance since, the 2020 proposal to lower the cross-border threshold to $250, was withdrawn in April 2025, as the guide on the 31 CFR 1010.410 travel rule in plain words explains.

Meanwhile the message the rule regulates has changed twice. Fedwire cut over to ISO 20022 on July 14, 2025, and from that day participants could use the CPMI's payments data models for high-value dollar wires (Fed360, June 2, 2026). The next Fedwire release, which brings the hybrid postal address for key parties, has been rescheduled to November 2027, with final usage guidelines due in November 2026 (Fedwire November 2027 release FAQ).

What does ISO 20022 change for the travel rule?

Nothing in the rule and a great deal in the data. The address now has defined elements: Fedwire's "interim" format allows structured or unstructured address information but not both, and the "hybrid/end-state" format requires a country code and a town at the least, with up to two free-text lines of 70 characters (Fedwire ISO 20022 format FAQ; the ISO 20022 town name follows that one field). Until the November 2027 release, Fedwire supports only unstructured and structured formats for key parties, and the Federal Reserve is urging senders to move to structured addresses now (the Fedwire ISO 20022 implementation delay).

Two other details matter to a travel rule check. Every value message must carry a UETR, which Fedwire checks for format but not for uniqueness (IMAD, OMAD and UETR), so a reply can be matched to its wire as long as senders generate the reference properly. And Fedwire's format is not a compliance standard: on the creditor's address it sends senders to their own compliance and legal teams (originator information on wire transfers quotes the advice). A message can be valid for Fedwire and still miss what the travel rule or a receiving bank requires.

A domestic Fedwire with the originator address missing, queued like any other gap

How to read an old clause against today's message

The Fedwire clause is a clean example of a general problem in compliance work: a rule's text outlives the facts it was written for. The method below is how we would read any such clause, and it is how the solution's rule settings are reviewed.

The solution's practical answer follows from that reading. Its Field agent requires the originator's address on Fedwire and SWIFT wires alike, cites (f)(1)(ii) when it is missing, and, for the bank's own outbound wires, its Record agent looks for the address in the core banking system before cut-off so the wire does not leave short. The modern causes of the same gap are channels, not formats: on the sample bank, one online-banking template that drops the address for older payees accounted for 4 of a day's 7 outbound gaps.

The bank's own wire missing the originator address, fixed from its own data before release

For what each bank in a Fedwire chain must keep and send, see funds transfer recordkeeping requirements, bank by bank; to see the full field list applied to your own Fedwire traffic, start from Funds Transfer Recordkeeping & Travel Rule.

Questions people ask

What is the travel rule safe harbor?

Paragraph (f)(3) of 31 CFR 1010.410, added in 1996: before a bank converted to the expanded Fedwire format, it was deemed compliant if it sent the amount, date, recipient's institution and recipient items received, and supplied the originator's name, address and its own identity on request within a reasonable time. It applies only before conversion, which FinCEN expected by the end of 1997.

Does the Fedwire exception apply to CHIPS or SWIFT wires?

No. The text names only "a transmittal order through Fedwire" and the sending bank's conversion to "the expanded Fedwire format". Wires on other systems never had the exception, and the originator's address has always been required on them.

Is the beneficiary's address required on a Fedwire?

Not by the travel rule unless it was received, and not by Fedwire's format: the Federal Reserve's FAQ says its specifications do not require the creditor's postal address in a pacs.008, and tells senders to check their compliance obligations and the receiving bank's requirements.

Is a UETR required on Fedwire payments?

Yes. The UETR is mandatory in Fedwire value messages (pacs.008, pacs.009, pacs.004). Fedwire checks that it has the proper format but does not check that it is unique, so a bank's own systems must generate it correctly.

Was 31 CFR 103.33(g) the travel rule?

Yes. FinCEN issued the travel rule in 1995 as 31 CFR 103.33(g), and documents of the 1990s and 2000s, including the 2009 interagency guidance on cover payments, cite it by that number. It now sits at 31 CFR 1010.410(f).

Could a bank still rely on customer-file addresses on a wire?

In certain circumstances, yes, under a later and separate interpretation: the FFIEC manual records that FinCEN's 2003 interpretation lets the address be the one in the bank's automated customer information file, including a P.O. box, as long as the bank keeps the customer's address on file and can retrieve it for law enforcement.