How to parse the remitter's country out of SWIFT tag 50F

What the “F”?

The 50F tag is an important variant on the tag 50 you know and love. Adopted at about the same time that the European Union enacted EU 1781/2006, the tag provided a structure for remitter data that banks in the EU/EAA could use in building their compliance programs. (Further details about EU 1781, and other payments transparency legislation will be the topic of a separate post. This post is the non-nonsense, high-speed, low drag guide to getting some critical data out of your wire messages and into your AML systems)

Step 1. Focus on the messages where 50F can be used.

The 50F tag can appear in the following messages;

• MT101
• MT102
• MT102+
• MT103
• MT103+
• MT202COV
• MT205COV
• CHIPS encapsulations of SWIFT Covers
• FedWire encapsulations of SWIFT Covers

Tag 50 can be thought of as having 2 main components; account or identifier information and the name/address block of data. In tag 50F, both components can contain the ISO country code related to the remitter's address.

Step 2. Get the ISO country codes out of the account or identifier information.

Special codes in 50F, when present, they are always in line 1 of tag 50F, taking the place normally showing the remitter's account number.

Code	Description	Location of ISO country code ('AQ' used as example)
ARNU	Alien Registration Number	ARNU/AQ/9999999999999
CCPT	Passport Number	CCPT/AQ/99999999999999
CUST	Customer Number	CUST/AQ/9999999999999
DRLC	Driver's License	DRLC/AQ/999999999999
NIDN	National Identity Number	NIDN/AQ/999999999999
SOSE	Social Security Number	SOSE/AQ/999999999999
TXID	Tax Identification Number	TXID/AQ/999999999999

Step 3. Get the ISO country codes out of the name/address block

In the 'name and address' portion of tag 50, the country ISO code is shown immediately after any appearance of “3/”, “7/” or “8/”.

Here's an example of the ISO code found using “3/”;

:50F:/GB29PNBP60161331926819

1/FELICITY ASHTON

2/BLDG 155

3/AQ/MCMURDO STATION

7/ is another way to provide a customer identification number, and is different in syntax from the special code “CUST”. It would be:

7/AQ/issuer-id-code/customer-id-number

8/is another way to provide a national ID number, and is different in syntax from the special code “NIDN”. It would appear as;

8/AQ/national-id-num

Recap

Cut and paste these steps into your to-do list or project plan to make sure you're getting the remitter's country code out of SWIFT tag 50F;

Step 1. Focus on the messages where 50F can be used. (101, 102, 102+, 103, 103+, 202COV, 205COV, and don't forget the CHIPS and FedWire encapsulations of SWIFT covers may have the tags as well.

Step 2. Get the ISO country codes out of the account or identifier information. Parse on “ARNU/”, “CCPT/”, “CUST/”, “DRLC/”, “NIDN/”, “SOSE/” and “TXID/”. Take the next two characters. They are the 2-letter ISO country code.

Step 3. Get the ISO country codes out of the name/address block. Parse on “3/”, “7/” and “8/”. Take the next two characters. They are the 2-letter ISO country code.

Happy hunting!

Has your AML system seen South Sudan yet?

In August, the International Standards Organization announced a new country. Well, a new ISO country code for a new country.

South Sudan.

The announcement detailed the new country code (SS), new currency code (SSD).

Overnight, 8.26 million people were in a new country.

Here's a checklist of things you might want to consider in your own AML, sanctions screening and compliance systems.

• Recognize the new country code. It'll start showing up on addresses, the party details on wires, information on letters of credit, currency transactions, and so on. It's a real country code, you should be able to recognize it.
• Recognize the new currency code. Again, you might start seeing it in FX transactions, in wire transfers and so on.
• Be on the lookout for new SWIFT BICs for banks operating in South Sudan. Some weeks after the ISO announcement, SWIFT will institute new BICs using the country code in positions 5 and 6, and will then migrate certain banks in the market to the new codes.
• Create a country risk rating for South Sudan. Maybe easier said than done, if you rely on third party information sources for rating data. You may have to establish an interim evaluation based on your assessment of the components of your country risk rating. (An upcoming post will show a DIY country risk-rating approach.)
• Assess the impact on your sanctions screening and OFAC processes. OFAC is going to a fair amount of trouble to exempt South Sudan from the current slate of Sudan country sanctions. (They're still a little stuck on how to craft language that will support South Sudan's oil industry. All the pipelines go through Sudan to reach the sea.) Focusing solely on the string “Sudan” will cause you to handle a lot false hits.

It's possible to turn this into a checklist that you can use every time the ISO organization formally assigns a new country code. South Sudan, the most recent, is a little more problematic than St. Bart's which was assigned a country this past December.

Yet, the key impacts will be the same;

• new country codes
• new bank Ids
• new currency codes
• new country risk assessment
• impacts on sanctions screening or proprietary list screening.

Three steps to dramatically improve the quality of your wire data.

Think back to the last time you reviewed a spreadsheet of wire transfer data from your AML data store. Did it seem to you that you were missing information in the originating bank role or the beneficiary bank role? What percent of the time did it feel like that information was missing?

If the answer is less than 5% of the time, stop reading.

If the answer is greater than 5% of the time, you've got some work to do. You're intelligent and experienced enough to know what kinds of problems missing wire data can cause an AML group; inaccurate profiling, incorrect alerts, incomplete search results, increased staff work load to get the missing data from the raw wire messages.

Fortunately, there are three simple steps to fix that problem.

1. Insist that every wire transfer has an originating bank and a beneficiary bank.
2. Map the originating bank by stepping through the optional and mandatory tags on the wire message.
3. Map the beneficiary bank by stepping through the optional and mandatory tags on the wire message.

First, insist that every wire transfer has an originating bank and a beneficiary bank. All of them. All the time. If either of those roles were truly missing, the money would not move. Practice saying this. Say it out loud now, just to hear it. Write it on a whiteboard. Make it a data quality standard.

Second, Map the Originating Bank.

In a SWIFT message, (the concept applies to FedWire and CHIPs messages, but we'll just talk about SWIFT for the moment) some parts of the message are optional, and some are mandatory. More importantly for you, there is a logical hierarchy to the information.

SWIFT tag 52 is the Ordering Institution, aka the originating bank. Tag 52 is an optional tag. I can't tell you the number of times I've had the following conversation when reviewing wire data.

“There's no originating bank on this wire record”

“There was no originating bank on the wire.”

“Really?”

“Sure, here's a copy of the wire message. We're supposed to look for tag 52 for the originating bank and put that information in the AML system. This one doesn't have a tag 52, so, we don't have an originating bank.”

Can you remember a conversation like that?

SWIFT, in its manuals, establishes rules and reasoning for interpreting the contents of a wire message, and to be successful in your wire monitoring, you need to make that reasoning part of the logic used to parse the wire message into effective AML information.

So, instead of this logic;

if tag 52 is present map contents to “originating bank”

else map blanks to “originating bank”

Use this logic:

If tag 52 is present, map contents to “originating bank”

else if tag 51 (Sending Institution) is present, map to “originating bank”

else map tag 2 (sending BIC in message header) to “originating bank”

Tags 52 and 51 are optional, but the sending BIC in the message header is mandatory. Even better, it has to be a valid BIC.

It's just as simple for a FedWire message;

if {5100} is present, map contents to “originating bank”

else map {3100} to “originating bank”

Third: Map the Beneficiary Bank.

Again, instead of stopping if an optional tag is not used; implement a mapping hierarchy that always ends on a mandatory field.

Instead of

if tag 57 (Account With Institution) is present, map the contents to “Beneficiary Bank”

else map blanks to “Beneficiary Bank”

use this simple substitution;

if tag 57 (Account With Institution) is present, map the contents to “Beneficiary Bank”

else map the BIC in tag 1 (receiving BIC) to “Beneficiary Bank”

Again, tag 1 is mandatory, and, bonus!! It's a valid BIC.

For the FedWire fans;

if {4100} is present, map the contents to “Beneficiary Bank”

else map {3400} to “Beneficiary Bank”.

{4100} is optional, but if it's used, it has the data you want. If it's not used, the {3400} tag, which is mandatory, has the data you need.

Three simple steps to vastly improve your AML wire transfer data;

1. Insist on populating the originating and beneficiary bank roles in every wire, every time.
2. Enhance your mapping logic to obtain the originating bank information.
3. Enhance your mapping logic to obtain the beneficiary.