Guiding principles
for screening
ISO 20022 payments

October 2021
V1.0

Contents

Guiding principles for screening ISO 20022 payments

1.

Enabling efficient and effective screening 

3

1.1

Introduction

4

1.2

ISO 20022

5

1.3

Approach6

1.4

Related market guidence

8

1.5

Targeted screening

9

1.6

Timing of ISO 20022 adoption

10

1.7

Risk-based approach to targeted screening

11

2.

Guiding principles for screening ISO 20022 payments

12

2.1

List elements to match against

13

2.2

Business components and data elements within transactions

15

2.3

How to read the guiding principles

16

2.4

Guiding principles for data elements

17

2.5

Examples2521.

Guiding principles for screening ISO 20022 payments

Enabling efficientand effective
screening3

1.1
Introduction

In 2020, SWIFT set out its new strategy to enable instant andfrictionless transactions, anywhere in the world, supported by smart
data and mutualised services. This strategy builds on the success of
SWIFT gpi, which was created to address frictions that slow downtransactions, adversely affect customer experience and add costs
to payments processing. As the payments landscape changes to an
instant 24/7 model and customer expectations grow, there is a needto further address sanctions-related friction in the payment chain.
The adoption of ISO 20022 and the CBPR+ usage
guidelines supports this strategy by providing a global
and open standard for information exchange. ISO 20022
is being adopted by a growing number of payment
infrastructures and will become the new standard forcross-border payments starting in November 2022.
As sanctions-related friction is a growing challenge
for the financial services industry, SWIFT presented a
programme (‘SWIFT Sanctions Screening Programme’)for the community to remove sanctions friction throughcollective action.

One of this programme’s workstreams focuses ondata quality and screening practices, with the objective
to design and document screening practices andsupporting data quality principles for ISO 20022
messages through industry collaboration.
This document is the first deliverable of that workstream
and proposes guiding principles for effective and efficient
screening of ISO 20022 payments.

With the move towards
faster payments there isa growing need to tackle
sanctions-related frictionin the payment chain
Enabling efficient and effective screening4

1.2
ISO 20022

As the payments industry prepares to adopt ISO 20022, banks arerevisiting their screening environments to identify the impact of thismove and opportunities for change. The ISO message provides
more structured and granular information than their FIN equivalents.
ISO 200222 also provides the ability to include additional information,
which creates an opportunity for the industry to re-think existing
approaches to screening.
Unstructured data is a barrier to building effective
transaction screening and monitoring tools that mitigate
sanction and AML risks. Today, using unstructured data
regularly results in exception handling and significant
delays in a payment’s lifecycle. These delays are causedby the process of transaction due diligence (such asfiltering, monitoring) or when mapping data to or fromlegacy formats.
On the one hand, the additional data that can bepresented in ISO 20022 messages could lead to anincreased number of transaction screening hits. But,
contrasting this, the structure and granularity of an ISO
20022 messages allows a more targeted approach toscreening financial transactions, potentially reducing theoverall number of false positives and reducing associatedsanctions friction.

Quality of data and structure are therefore paramountto achieving an effective and efficient implementationof transaction screening and monitoring tools. Financial
institutions have an opportunity to leverage the adoptionof ISO 20022 to ensure their systems and applications
provide and map structured data for all parties involved in
the transaction.
The guiding principles described in this document
represent a ‘target state’, defined by the industry based
upon a mature adoption of ISO 20022. Readers areinvited to consider whether these principles are alignedwith their institution’s risk appetite, and monitor thequality of data in ISO 20022 payments when applying theprinciples.

The granular structureof ISO 200222 createsan opportunity for theindustry to re-think existing
approaches to screening.
Enabling efficient and effective screening

5

1.3
Approach

Representatives from 14 global and regional banks took part in aseries of workshops, analysing the pacs.008 message with the
purpose of defining:
Which ISO 20022 elements should be screened and whichshould not.
How to best match these ISO 20022 elements against
sanctions lists.
What data quality principles should be observed to support
effective and efficient transaction screening.
The conclusions of these workshops and analysis are summarised inthis document.

The industry has
collaborated to produce
screening guidelines for
ISO 20022
Enabling efficient and effective screening

While the initial analysis focused exclusively on pacs.008 messages
following the CBPR+ usage guidelines, the screening guidelines may
be leveraged when performing similar analysis on other messages
such as pacs.009 COV, pacs.004 and other messages that banks
consider relevant to screen. These principles may evolve on aregular basis to cover additional messages, data elements or usage
guidelines.

6

Observations from screening FIN messages
Over the past 5 years, SWIFT has conducted benchmarks
with 40 organisations, representing more than 50% of thetotal SWIFT traffic. This captures market practices related
to the way MTs are currently being screened and which
fields are most commonly screened by banks. Theseobservations constitute a solid representation of current
market practices and have informed this analysis on ISO
20022 screening.
Screening practices for FIN MT 103 messages show that:• Fields containing dates, amounts, charges,
transaction references and codes are usually not
subject to screening.
• Fields that the most banks screen include:
Party fields (Field 50, Field 59).
These are by far the greatest source of hits dueto 1) the free format nature of the informationand 2) the mismatches between data types(address information matching against names).
o Bank identification fields (Sender BIC, Receiver
BIC, Fields 52 to 57)
These can be a source of friction when free format
names and addresses are used rather than a BIC.
o Narrative fields: Remittance information(Field 70) and Sender to Receiver information(Field 72) also generate significant hits due
the free format nature of these fields.
oIndustry screening practiceField Field

Field nameField is screened

Field is not screened

Header Block 1

Message Sender (BIC)

83%

17%

Header Block 2

Message Receiver (BIC)

86%

14%

20

Sender’s Reference

27%

73%

13C

Time Indication

27%

73%

23B

Bank Operation Code

30%

70%

23E

Instruction Code

46%

54%

26T

Transaction Type Code

35%

65%

32A

Value Date/Currency/Interbank Settled Amount

41%

59%

33B

Currency/Instructed Amount

38%

62%

36

Exchange Rate

30%

70%

50a

Ordering Customer

100%

0%

52a

Ordering Institution

100%

0%

53a

Sender’s Correspondent

97%

3%

54a

Receiver’s Correspondent

97%

3%

55a

Third Reimbursement Institution

97%

3%

56a

Intermediary Institution

97%

3%

57a

Acount With Institution

97%

3%

59a

Beneficiary Customer

100%

0%

70

Remittance Information

95%

5%

71A

Details of Charges

35%

65%

71F

Sender’s Charges

41%

59%

71G

Receicer’s Charges

43%

57%

72

Sender to Receiver Information

97%

3%

77B

Regulatory Reporting

78%

22%

Table 1MT 103 Industry Screening Practice
Source: SWIFT’s screening survey 2020

This insight on existing MT screening practices has
informed priorities and areas of focus for ISO 20022
screening.

Enabling efficient and effective screening

7

1.4
Related market
guidance

This paper took into account the following market
guidance:

These guidance documents provide the foundation uponwhich our guiding principles are based as they:

The Wolfsberg Group
Wolfsberg Group Payment
Transparency Standards 2017 ↓

Wolfsberg Group Sanctions
Screening Guidance 2019 ↓

The Payment Market Practice Group (PMPG)
Structured ordering and beneficiary
customer data in payments ↓• Describe the data elements that are expected to
be included in payments.
• Describe the responsibilities of actors involved inprocessing payments.
• Confirm that financial institutions are expected toapply a risk-based approach to screening.
• State that financial institutions should identify
which data elements within transactions are
relevant for sanctions screening, and the context inwhich these data elements become relevant.
• Suggest that some data elements are relevant
to screen whilst others may not be – though theelements that do not need to be screened can beused as supporting information to help distinguisha true match from a false match.
The principles set out in this paper take these guidance
documents into account and provide a further levelof detail to support an approach known as ‘targeted
screening’.

Enabling efficient and effective screening

8

1.5
Targeted screening• What the relevant information should be screened
against.
o Records of Individuals, Entities, Vesselsor Aircrafts published on sanctions lists.
o BIC and LEI codes of Entities
published on sanctions lists.
o Embargo data (Countries, cities, ports …).

Unlike the MT message syntax where all data elements(account, name, address & other) about a party areamalgamated into a single field, the ISO 20022 syntax
has dedicated tags for each of these data elements.
This structure and granularity of the information makes it
possible to define:• How each data element can be used in thescreening process.
o Is the information relevant to trigger
a hit against sanctions data?
o Is the information within the data element
considered as purely additional information?
(i.e. not used to generate a match, but instead
used by operations as supporting information
to help distinguish a true match from afalse match on an alert raised on anotherpart of the message) e.g. a date of birth.

• What type of screening logic can be applied tothese tags and data elements:
o Fuzzy matching for all free format information.
o Exact matching for structured identifiers(ISO country codes, BICs, LEIs).
The targeted screening approach is best described as amatrix where transaction data elements and tags appear

in rows, while the information it can be matched against
is in columns. Each cell can then be used to provide therecommended screening behavior.
It is important to understand that no information is
discarded from the message when screening it. Instead,
only selected tags will be matched against list data. Any
information that is not screened may still be visible tosupport alert dispositions in case management tools.
The targeted screening approach allows financial
institutions to avoid false positives linked to mismatches
between information types (e.g. debtor name hitting
against vessel names, street name information hitting
against embargo data).

If screened, match it against

Table 2
Targeted screening
template

Enabling efficient and effective screening

Name

XML Tag

Mult

Type / Code

Name

<Nm>

[0..1]

text{1,140}

Postal Address<PstlAdr>[0..1]

Department<Dept>[0..1]

text{1,70}

Sub Department<SubDept>[0..1]

text{1,70}

Street Name

<StrtNm>[0..1]

text{1,70}

Building Number<BldgNb>[0..1]

text{1,16}

Building Name

<BldgNm>[0..1]

text{1,35}

Floor

<Flr>

[0..1]

text{1,70}

Post Box<PstBx>[0..1]

text{1,16}

Room<Room>[0..1]

text{1,70}

Post Code<PstCd>[0..1]

text{1,16}

Town Name<TwnNm>[0..1]

text{1,35}

Town Location Name

<TwnLctnNm>[0..1]

text{1,35}

District Name

<DstrctNm>[0..1]

text{1,35}

Country Sub Division<CtrySubDvsn>[0..1]

text{1,35}

Country<Ctry>[0..1]

text [A-Z]{2,2}Screen (Yes/No)

Individuals

Entities

Vessels

Aircrafts

BIC / LEI

EmbargoMatch Type9

1.6
Timing of
ISO 20022 adoption

Athough a number of domestic payment systems have alreadyadopted ISO 20022 or have plans to do so in the near future, we
expect the majority of financial institutions to gradually adopt ISO
20022 as their primary syntax when issuing a payment between
November 2022 and November 2025. There are several dimensions
in relation to ISO 20022 message formats that will need to beconsidered when adapting screening solutions:
Using ISO 20022 rather than MT as the syntax to issue
a payment.
Using the structured data elements within the ISO syntax(e.g. Postal Address).
Using the new data elements that do not exist in MT(ultimate parties, structured and rich remittance information).

Banks will need tocontinuously adapt theirscreening as ISO 20022
adoption matures during
the co-existence period
between 2022 and 2025.
Enabling efficient and effective screening

In terms of syntax (1), the pace of adoption will be primarily
driven by the market infrastructures (MIs) in which banks
participate. A number of large MIs (CHAPS, TARGET
Services) plan to adopt ISO 20022 in 2022 and we expect
a significant portion of payments to switch to the ISO
20022 syntax early in the co-existence period.
The adoption of the structured data elements within
the message (2) is harder to predict. Though the use ofstructured data is strongly recommended from day 1
and made mandatory as from 2025 or earlier by somepayment Market Infrastructures, the ability for banks andcorporates to map and provide this data in a structured
format involves updating many (front-end) applications.

The timing of adoption of new data elements (3) is also
subject to multiple considerations: in the early phase of theco-existence period, the inclusion of such data elements
could lead to increased truncation risk if the payment
needs to be processed through a Market Infrastructureor an agent that is not yet ISO 20022 ready. Therefore, it
is expected that in the early days of the adoption period,a so-called ‘like-for-like’ period will take place, and thatthe new data elements will progressively be adopted later
during the co-existence period.
As a result, it is difficult for financial institutions to anticipate
what they will receive and how the quality of the data in
ISO 20022 will evolve throughout the co-existence period.
10

1.7
Risk-based approach totargeted screening

The targeted screening principles described in thisdocument represent a ‘target state’ defined by the industry
based on mature adoption and stable data quality ofISO 20022 payments.
It is therefore important that financial institutions adopt a riskbased approach when implementing these guiding principles
and ensure that:
The adoption of the guiding principles is in line with thebank’s risk appetite.
Banks monitor the adoption of ISO 20022, in particular theuse of structured and new data elements.
Banks progressively adapt their screening to the guiding
principles in line with observed ISO 20022 adoption.

Financial institutions
must adopt a riskbased approach when
implementing these guiding
principles.
Enabling efficient and effective screening

11

2.

Guiding principles for screening ISO 20022 payments

Guiding principles forscreening ISO 20022
payments

12

2.1
List elements tomatch against

The lists that financial institutions load into their screening
systems contain multiple types of information which
influence the expected screening behaviour. As the typeof information contained in these lists evolve, so will theguiding principles. In this section we will review the maintypes of information contained in the lists that are used
for screening.
Most of the records contain primary attributes andunique identifiers (i.e. information that can be searched
for to create a hit) and secondary attributes (i.e.
information that will be used to further qualify an alert
resulting from matching against primary attributes).

Guiding principles for screening ISO 20022 payments

A. Individuals
These are the sanctions records of Individuals sourced
from public lists. These records contain:

B. Entities
These are the sanctions records of companies ororganisations sourced from public lists. These records contain:

Primary
attributes

Primary name
AKA*(s) (Strong) - * Also known as

Primary
attributes

Primary name
AKA(s) (Strong)

Uniqueidentifiers

Passport numbers
National ID numbers…

Uniqueidentifiers

Secondary
attributes

AKA(s) (Weak)
Addresses
Ownership and control (as suppliedby regulators)
Date of birth, place of birth
TitlesSanction designation information

Bank Identifier Code(s) / BIC(s)Legal Entity Identifiers / LEI(s)Other Identifiers (company
registration number, tax
identification, …)

Secondary
attributes

AKA(s) (Weak)
Addresses
Ownership and control (as suppliedby regulators)
Sanction designation information

13

C. Vessels
Some public sanctions lists contain designations related
to vessels. These records can contain:

D. Aircrafts
Some public sanctions lists contain designations related
to aircrafts. These records can contain:

Primary
attributes

Primary name
AKA(s) (Strong)

Primary
attributes

Primary name
AKA*(s) (Strong) - * Also known as

UniqueidentifiersInternational Maritime Organisation
number (IMO)
Maritime Mobile Security Identity(MMSI)

Uniqueidentifiers

Manufacturer Serial Number (MSN)

Secondary
attributes

Aircraft model
Construction number
Ownership and control (as suppliedby regulators)
Sanction designation information

Secondary
attributes

Vessel type
Flags
Ownership and control (as suppliedby regulators)
Sanction designation information

E. BIC / LEI
BICs and LEIs are not explicitly a category of designations
like the previous 4 categories above. Rather, in the context
of sanctions, they are unique identifiers of sanctioned
entities. Unlike other identifiers, BICs and LEIs are global
in nature which make them particularly effective to identify
sanctioned entities or discard potential hits.

F. Embargo
The industry common practice is to use country-based
screening data for countries that are subject to broad
embargo restrictions, also known as comprehensive
sanctions. It is not common practice to use countrybased screening data for countries where the applicablesanctions program is purely list-based.

In addition, BICs are the primary means of identification
for financial institutions on the SWIFT network, where thecore of international transactions is processed and containa country code which is relevant for embargo screening.
The guiding principles will therefore refer to them as aseparate category.

Embargo data comprises all the information that financial
institutions source to assist with country-based screening
obligations.

Some regulators include BIC in their designations whileothers do not. Most data vendors will enrich their feed ofsanctions data with BIC for financial institutions that aredesignated.

Primary
attributes

Country names
ISO Country codes
CTRP’s (cities, towns, regions, ports,
airport names)

There are 2 methods commonly applied by the industry to
screen a BIC:
1. Matching the BIC against list of sanctioned BICs
and the BIC country code against Embargo data.
This is the most effective and efficient method but
requires lists that are enriched with BICs (typicallyby a 3rd-party vendor).
2. Converting the BIC into its Name and Addressusing a SWIFTRef product, then matching theName and Address against sanctioned Entity and
Embargo data. This method is the fallback option
and provides a compensating control for when a
BIC has not yet been identified, or for when the lists
are not enriched with BICs but generate more false
positives.

Guiding principles for screening ISO 20022 payments

14

2.2
Business components
and data elements withintransactions

Transactions contain multiple business components,
which themselves contains data elements. This section
covers the main types of data elements and describes
whether the information contained in their tag(s) is relevant
for screening or considered as additional information.
The data elements can be present in multiple places
within a payment. For example, Name can appear in
Debtor (Party Identification), Creditor (Party Identification)but equally in Debtor Agent (Financial Institution
Identification), etc. We will therefore provide guiding
principles for the data elements that are most relevant forscreening.

In most cases, the guiding principles will apply wherever
the data element appears in a transaction. In some cases
however, the business components in which they arepresent will influence the screening principle.
In line with the Wolfsberg guidance on sanctions
screening, business components such as amounts, dates
and transaction reference numbers have no relevancefrom a screening perspective and will therefore not be
explicitly covered. Financial institutions need to ensure,
however, that this is line with their risk-appetite.

Business components

Data Element
Name

Postal Address

Identification

Party Identification

X

X

X

Financial Institution Identification

X

X

X

Accounts

X

Unstructured
Information

Country of Residence
X

X

Instruction for Creditor/next AgentX

Regulatory Reporting

X

X

Related Remittance Information

X

X

Remittance Information

X

X

X

X

X

Table 3
Data elements to Business components mapping

Guiding principles for screening ISO 20022 payments

15

2.3
How to read the guiding
principles

YES means tag content should be
used to trigger hits

If XML tag is to be used to trigger
hits, what list content should it bematched against

RA (Risk Appetite) means thatsome organisations consider the
tag content could be used totrigger hits
Blank cell means tag is consideredadditional info to further qualify hits
during alert disposition

If screened, match it against
Name

XML Tag

Mult

Debtor<Dbtr>[1..1]Name<Nm>[0..1]

Type / CodeScreen (YES/NO)

Individuals

Entities

text{1,140}

YES

YES

YES

Vessels

Aircrafts

BIC / LEI

EmbargoMatch Type

RA

RA

FUZZY

Table 4
How to read guiding principles

YES meanstag should
be matchedagainst list
information
Guiding principles for screening ISO 20022 payments

Blank cellmeans tagshould not bematched against
list information

RA means that
it is common
Risk Appetite
for banks tomatch tagagainst list
information

Indicates ifmatch typeis Fuzzy or
Exact
16

2.4
Guiding principles fordata elements

Guiding principles for screening ISO 20022 payments

The following section provides the details of the targeted
screening approach supported by the industry for ISO
20022 messages. This publication seeks to document themarket practices for screening ISO 20022 messages. It
was created in consultation and based on the feedback ofa group of SWIFT customers representing a large portionof SWIFT’s traffic. As a mere informative publication, it is
not designed to provide any recommendation or advice tothe recipient, and should not be used as such.

The guiding principles assume that the recipient is familiar
with the ISO 20022 message syntax for a pacs.008.
Supporting information can be found on SWIFT’s website:

Downloads
ISO 20022 for dummies ↓

ISO 20022 CBPR+ user handbook ↓

MyStandards

↓

17

A.
Name <Nm>
In most cases, the Name tag refers to the name by whicha party or agent is known, which is usually used to identify
that party or agent. It is therefore expected that financial
institutions will screen this tag.

Data quality principles

Guiding principle for screening

Risk Appetite

The Name tag should not contain other elements than aname. BIC and other identifiers must be included in theirrespective fields.

When present in Party Identification and Remittance
Information, the tag should be matched against records of
Individuals & Entities (Table 5).

For natural person customers (aka Individuals), the namerecorded in the financial institution’s systems should be
the full name of the customer that was verified as part ofCustomer Due Diligence (CDD).

When present in Financial Institution Identification, the tag
should be matched against records of Entities (Table 6).

Some financial institutions indicate they may screen
Name tags against Embargo data to detect a possible
connection with sanctioned countries in the Name itself(Table 5 & 6).

For legal entity customers, the financial institution should
place preference on the registered legal entity nameverified as part of CDD.
For names of beneficiary party(ies), financial institutions
should include the name of the beneficiary as provided by
the originator of the transaction.
If screened, match it against
Name

XML Tag

Mult

Debtor<Dbtr>[1..1]Name<Nm>[0..1]

Type / CodeScreen (YES/NO)

Individuals

Entities

text{1,140}

YES

YES

YES

Vessels

Aircrafts

BIC / LEI

EmbargoMatch Type

RA

FUZZY

EmbargoMatch Type

RA

FUZZY

Table 5
Screening Name in Party Identification and Remittance Information

If screened, match it against
Name

XML Tag

Mult

Debtor Agent<DbtrAgt>[1..1]

Financial Institution Id.

<FinInstnId>[1..1]<Nm>[0..1]

Name

Type / CodeScreen (YES/NO)

text{1,140}

YES

Individuals

Entities

YES

Vessels

Aircrafts

BIC / LEI

Table 6
Screening Name in Financial Institution Identification

Guiding principles for screening ISO 20022 payments

18

B.
Postal Address
The Postal Address is the information that locatesand identifies a specific address, as defined by postal
services. The Postal Address data element contains
multiple tags which can be used for:• Structured address details. In such case thecomponents of the address will be included in theirrespective tags.
• Unstructured address details. In this case all
the information will be included in a single tag
which can be repeated as required to include all
information.
Note that, according to the CBPR+ usage guidelines,
the unstructured and structured address tags aremutually exclusive. Furthermore, it is expected that the
unstructured address tags will be decommissioned in
2025.

Structured Postal Address
Data quality principles

Guiding principle for screening

Risk Appetite

The structured Postal Address option is preferred.

When using the structured Postal Address tag, thefollowing tags should be screened if present: Town
Name, Town Location Name, District Name, Country Sub
Division, Country. These elements will be matched against
Embargo data (Table 7).

Some financial institutions indicate they may screen
Department and Sub Department tags against Embargo
data to identify a possible connection with sanctioned
countries (Table 7).

Financial institutions are expected to include informationaccording to the resident country convention. At aminimum, Town Name and Country must be present.
Post Code is recommended.

Some financial institutions indicate they may screen
Post Code tags against Embargo data to detect apossible connection with sanction programmes when the
programme targets a specific region, not a country(Table 7).
If screened, match it against

Name

XML Tag

Mult

Type / CodeScreen (Yes/No)

Postal Address<PstlAdr>[0..1]

Department<Dept>[0..1]

text{1,70}

Sub Department<SubDept>[0..1]

text{1,70}

Street Name

<StrtNm>[0..1]

text{1,70}

Building Number<BldgNb>[0..1]

text{1,16}

Building Name

<BldgNm>[0..1]

text{1,35}

Floor

<Flr>

[0..1]

text{1,70}

Post Box<PstBx>[0..1]

text{1,16}

Room<Room>[0..1]

text{1,70}

Post Code<PstCd>[0..1]

Town Name<TwnNm>Town Location Name

Individuals

Entities

Vessels

Aircrafts

BIC / LEI

EmbargoMatch Type

RA

RA

FUZZY

RA

RA

FUZZY

text{1,16}

RA

RA

EXACT

[0..1]

text{1,35}

YES

YES

FUZZY

<TwnLctnNm>[0..1]

text{1,35}

YES

YES

FUZZY

District Name

<DstrctNm>[0..1]

text{1,35}

YES

YES

FUZZY

Country Sub Division<CtrySubDvsn>[0..1]

text{1,35}

YES

YES

FUZZY

Country<Ctry>[0..1]

text [A-Z]{2,2}

YES

YES

EXACT

Table 7
Screening structured Postal Address

Guiding principles for screening ISO 20022 payments

19

Unstructured Postal Address
Data quality principles

Guiding principle for screening

Risk Appetite

Financial institutions are expected to include informationaccording to the resident country convention. At aminimum, Town Name and Country must be present.
Post Code is recommended.

When using the unstructured Postal Address tag, theentire tag should be screened against embargo data.
If the tag is repeated (up to 3 lines), the information should
be concatenated to be screened to avoid risks that
information split over 2 lines causes the filter to miss it(Table 8).

Some financial institutions indicate they may screen
Address Line against Individuals and Entities to cater forcases where MT/MX translation tools are used, as there
is a possibility that the name information in field 50 carries
over to the second line, and in such case it could end-up
in the Address Line (Table 8).
If screened, match it against

Name

XML Tag

Mult

Postal Address<PstlAdr>[0..1]

Address line

<AdrLine>[0..3]

Type / CodeScreen (YES/NO)

Individuals

Entities

text{1,35}

YES

RA

RA

Vessels

Aircrafts

BIC / LEI

EmbargoMatch Type

YES

FUZZY

Table 8Screening unstructured Postal Address

20

C.
Identification
Identification provides unique and unambiguous
identification of a party. The data element provides
the ability to identify:
An organization - using the Identification/
Organisation tag(s).
An individual - using the Identification/Private
Identification tag(s).

Organisation identification
Data quality principles

Guiding principle for screening

Risk appetite

In case the party is an organisation, the use of a BIC in
the Organisation ID/AnyBIC tag in combination with an
Account Number or Organisation ID/Other can serveas the primary source of identification for the party
and replace the Name and Postal Address. Structured
identifiers are more efficient for screening purposes thanfree text names and addresses (Table 9).

When using the Organisation Identification, the following
tags should be screened if present:• Any BIC will be screened against lists of sanctioned
BICs and Embargo data related to countries (using
the 5th and 6th characters of the BIC) (Table 9).
• LEI will be screened against list of sanctioned
LEIs (if any). If geographical information can beinferred from the LEI, it should be screened against
Embargo data (Table 9).
• Other Identification should be screened against
relevant identifiers of sanctioned Entities (Table 9).
• The Issuing Organisation of the Other Identification
should be screened against sanctioned Entities(Table 9).

Some financial institutions may screen BIC and LEI
against sanctioned Entities after expanding the identifiers
into full name and address if their lists are not enrichedwith BICs and LEIs (Table 9).
Some financial institutions indicate they may screen Other
Identification against sanctioned Individuals to identify
potential ownership and control linkages (Table 9).
Some financial institutions indicate they may screen Issuer
against Embargo data to identify a possible connection
with sanctioned countries (Table 9).

If screened, match it against
Name

XML Tag

Mult

Type / CodeScreen (Yes/No)

Identification<Id>[0..1]

ChoiceOrganisation Identification<OrgId>[1..1]

Any BIC<AnyBIC>[0..1]

BIC

YES

LEI

<LEI>

[0..1]

LEI

YES

Other

<Othr>[0..*]

Identification<Id>[1..1]

text{1,35}

YES

Scheme Name

<SchmeNm>[0..1]

ChoiceCode<Cd>[1..1]

text{1,4}

Proprietary<Prtry>[1..1]

text{1,35}

Issuer<Issr>[0..1]

text{1,35}

YES

Individuals

RA

Entities

Vessels

Aircrafts

BIC / LEI

EmbargoMatch Type

RA

YES

YES

EXACT

RA

YES

YES

EXACT

YES

YES

EXACT

RA

FUZZY

Table 9
Screening Organisation Identification

Guiding principles for screening ISO 20022 payments

21

Private Identification
Data quality principles

Guiding Principle for screening

Risk appetite

In case the party is an Individual, the use of Private
Identification in addition to Name and Postal Address
is recommended if Account Number is not included.
Inclusion of additional identifiers are likely to facilitate thealert disposition process (Table 10).

When using the Private Identification, the following tags
should be screened if present:• Other Identification should be screened against
relevant identifiers of sanctioned Individuals (Table
10).
• The Issuing Organisation of the Other Identification
should be screened against sanctioned Entities(Table 10).

Some financial institutions indicate they may screen
Other Identification against sanctioned Entities to identify
potential ownership and control linkages (Table 10).
Some financial institutions indicate they may screen Issuer
against Embargo data to identify a possible connection
with sanctioned countries (Table 10).

If screened, match it against
Name

XML Tag

Mult

Type / CodeIdentification<Id>[0..1]

ChoicePrivate Identification<PrvtId>[1..1]

Date And Place Of Birth<DtAndPlcOfBirth>[0..1]

Birth Date

<BirthDt>[1..1]

date

Province Of Birth<PrvcOfBirth>[0..1]

text{1,35}

City Of Birth<CityOfBirth>[1..1]

text{1,35}

Country Of Birth<CtryOfBirth>[1..1]

text [A-Z]{2,2}<Othr>[0..*]

Identification<Id>[1..1]

text{1,35}

Scheme Name

<SchmeNm>[0..1]

ChoiceCode<Cd>[1..1]

text{1,4}

Proprietary<Prtry>[1..1]

text{1,35}<Issr>[0..1]

text{1,35}

Other

IssuerScreen (Yes/No)

Individuals

Entities

YES

YES

RA

YES

YES

Vessels

Aircrafts

BIC / LEI

EmbargoMatch Type

EXACT

RA

FUZZY

Table 10
Screening Private Identification

Guiding principles for screening ISO 20022 payments

22

D.
Country of residence
Country in which a person resides (the place of a person’shome). In the case of a company, it is the country fromwhich the affairs of that company are directed.

Data quality principles

Guiding principle for screening

Country of Residence (where the party physically lives)
should be used only if different from Postal Address/
Country (country linked to the owner of the account used
for contact purposes).

When used, Country of Residence should be screened
against Embargo data (Table 11).

If screened, match it against
Name

XML Tag

Mult

Type / CodeScreen (YES/NO)Country Of Residence<CtryOfRes>[0..1]

text [A-Z]{2,2}

YES

Individuals

Entities

Vessels

Aircrafts

BIC / LEI

EmbargoMatch Type

YES

EXACT

Table 11
Screening Country Of Residence

Guiding principles for screening ISO 20022 payments

23

E.
Unstructured information
Free format information tags are present in a numberof business components such as the Remittance
Information, Instruction for Next Agent, Instruction for
Creditor Agent, Regulatory reporting, etc.
The Remittance Information business component
provides 2 options that are mutually exclusive:• Unstructured remittance information: Information
supplied to enable the matching/reconciliation of an
entry with the items that the payment is intended tosettle, such as commercial invoices in an accounts’receivable system, in an unstructured form.
• Structured remittance information: same as above
in a structured form. Note that the structured
remittance information field contains multiple tags,
some of which are unstructured.

Guiding principles for screening ISO 20022 payments

Guiding principle for screening
When present, unstructured information tags should bescreened against all list elements (Table 12).
If screened, match it against
Name

XML Tag

Mult

Type / CodeScreen (YES/NO)

Individuals

Entities

Vessels

Aircrafts

BIC / LEI

EmbargoMatch Type

Unstructured<Ustrd>[0..*]

text{1,140}

YES

YES

YES

YES

YES

YES

YES

FUZZY

If screened, match it against
Name

XML Tag

Mult

Type / CodeScreen (YES/NO)

Individuals

Entities

Vessels

Aircrafts

BIC / LEI

EmbargoMatch Type

Additional Remittance Info

<AddtlRmtInf>[0..*]

text{1,140}

YES

YES

YES

YES

YES

YES

YES

FUZZY

If screened, match it against
Name
Instruction Information

XML Tag

Mult

Type / CodeScreen (YES/NO)

Individuals

Entities

Vessels

Aircrafts

BIC / LEI

EmbargoMatch Type<InstrInf>[0..*]

text{1,140}

YES

YES

YES

YES

YES

YES

YES

FUZZY

Table 12
Screening unstructured information tags

24

2.5
ExamplesGuiding principles for screening ISO 20022 payments

The following pages provide examples of applying the guiding
principles to the Debtor (Party identification) and Debtor Agent(Financial Institution identification) within a pacs.008 message.

25

Applying the guiding principles to a Debtor (party identification) in a pacs.008 message

Table 13screening Debtor (party identification) in a pacs.008 message
If screened, match it against

Name

XML Tag

Mult

Debtor<Dbtr>[1..1]

Type / CodeScreen(YES/NO)

Individuals

Entities

Vessels

Aircrafts

BIC / LEI

Embargo

Match
Type

Notes

Individuals: Screen against names of individuals on lists
text{1,140}

YES

YES

YES

RA

RA

FUZZY

Entities: Screen agains names of entities on lists

Name

<Nm>

[0..1]

Postal Address<PstlAdr>[0..1]

Department<Dept>[0..1]

text{1,70}

RA

RA

FUZZY

Embargo: Rationale is to detect possible connection with sanctioned countries if no other geograpical information is supplied

Sub Department<SubDept>[0..1]

text{1,70}

RA

RA

FUZZY

Embargo: Rationale is to detect possible connection with sanctioned countries if no other geograpical information is supplied

Street Name

<StrtNm>[0..1]

text{1,70}

Building Number<BldgNb>[0..1]

text{1,16}

Building Name

<BldgNm>[0..1]

text{1,35}

Floor

<Flr>

[0..1]

text{1,70}

Post Box<PstBx>[0..1]

text{1,16}

Room<Room>[0..1]

text{1,70}

Post Code<PstCd>[0..1]

text{1,16}

RA

RA

EXACT

Embargo: Rationale is to detect possible connection with sanction programmes when it targets a specific region, not a country

Town Name<TwnNm>[0..1]

text{1,35}

YES

YES

FUZZY

Embargo: Rationale is to detect possible connection with sanctioned countries

Town Location Name

<TwnLctnNm>[0..1]

text{1,35}

YES

YES

FUZZY

Embargo: Rationale is to detect possible connection with sanctioned countries

District Name

<DstrctNm>[0..1]

text{1,35}

YES

YES

FUZZY

Embargo: Rationale is to detect possible connection with sanctioned countries

Country Sub Division<CtrySubDvsn>[0..1]

text{1,35}

YES

YES

FUZZY

Embargo: Rationale is to detect possible connection with sanctioned countries

Country<Ctry>[0..1]

text [A-Z]{2,2}

YES

YES

EXACT

Embargo: exact match of ISO 2 country code against embargo data

Address Line

<AdrLine>[0..7]

text{1,70}

YES

YES

FUZZY

Identification<Id>[0..1]

ChoiceOrganisation Identification<OrgId>[1..1]

Embargo: Rationale is to detect possible connection with sanctioned countries if no other geograpical information is supplied
BIC: Rationale is to detect cases where a BIC is used in <Nm> rather than <AnyBIC>

RA

RA

text
Any BIC<AnyBIC>[0..1][A-Z0-9]{4,4}[A-Z]{2,2}[A-Z0-9]{2,2}([A-Z0-9]{3,3})

LEI

<LEI>

Other

[0..1][A-Z0-9]{18,18}[0-9]{2,2}<Othr>[0..*]

Identification<Id>[1..1]

text{1,35}

Scheme Name

<SchmeNm>[0..1]

ChoiceCode<Cd>[1..1]

text{1,4}

Proprietary<Prtry>[1..1]

text{1,35}<Issr>[0..1]

text{1,35}

Private Identification<PrvtId>[1..1]

Date And Place Of Birth

Issuer

YES

RA

YES

YES

EXACT

Entities: expand LEI into full name and match against Entities (fuzzy)
YES

YES

[0..1][1..1]

date

Province Of Birth<PrvcOfBirth>[0..1]

text{1,35}

City Of Birth<CityOfBirth>[1..1]

text{1,35}

Country Of Birth<CtryOfBirth>[1..1]

text [A-Z]{2,2}<Othr>[0..*]

Identification<Id>[1..1]

text{1,35}

Scheme Name

<SchmeNm>[0..1]

ChoiceCode<Cd>[1..1]

text{1,4}

Proprietary<Prtry>[1..1]

text{1,35}<Issr>[0..1]

text{1,35}

YES<CtryOfRes>[0..1]

text [A-Z]{2,2}

YES

Guiding principles for screening ISO 20022 payments

RA

YES

<BirthDt>

Country Of Residence

RA

YES

YES

EXACT

LEI: Screen against LEIs in sanctioned Entities
Embargo: if possible identify geographical or LOU (Local Operating Unit) from LEI and match Embargo Data

<DtAndPlcOfBirth>

IssuerEmbargo: exact match of BIC country (position 5-6) against embargo data
Entities: alternative if no list of sanctioned BICs - expand the BIC into full name and match against list of entities (fuzzy)

Birth Date

Other

Individuals /Entities: Rationale is to detect sanctioned parties in case part of the name appears in the adress line when using MT/MX translation tools

BIC: Screen as exact match against lists of BICs of sanctioned Entities (possibly enriched by List supplier)

{0,1}
text

Embargo: Rationale is to detect possible connection with sanctioned countries

YES

YES

YES

YES

EXACT

RA

RA

YES

FUZZY

EXACT

RA

FUZZY

YES

EXACT

Individuals: Rationale is to detect links between companies owned by sanctioned individuals
Entities: Screen against identifiers of sanctioned Entities

Entities: Screen against names of Entities on lists
Embargo: Rationale is to detect possible connection between issuer and Sanctioned countries

Individuals: Screen against identifiers of sanctioned Individuals
Entities: Rationale is to detect links between companies owned by sanctioned individuals

Entities: Screen against names of Entities on lists
Embargo: Rationale is to detect possible connection between issuer and Sanctioned countries
Embargo: exact match of ISO 2 country code against embargo data

26

Applying the guiding principles to a Debtor Agent (Financial Institution Identification) in a pacs.008 message

If screened, match it against
Name

XML Tag

Mult

Debtor Agent<DbtrAgt>[1..1]<FinInstnId>[1..1]

Financial Institution
Identification

Type / CodeScreen(YES/NO)text [A-Z0-9]{4,4}[A-Z]{2,2}[A-Z0-9]{2,2}([A-Z0-9]{3,3})
{0,1}

YES

BICFI

<BICFI>[0..1]

Clearing System
Member Identification<ClrSysMmbId>[0..1]<ClrSysId>[0..1]

Choice<Cd>[1..1]

text{1,5}

Clearing System
Identification
Code

Member Identification

LEI<MmbId><LEI>[1..1]

text{1,35}[0..1]

text [A-Z0-9]{18,18}[0-9]{2,2}

Name

<Nm>

[0..1]

Postal Address<PstlAdr>[0..1]

Department<Dept>Sub Department

Individuals

Entities

YES

Vessels

Aircrafts

BIC / LEI

Embargo

Match
Type

Notes

YES

YES

EXACT

BIC: Screen as exact match against lists of BICs of sanctioned Entities (possibly enriched by List supplier)Embargo: exact match of BIC country (position 5-6) against embargo data

EXACT

BIC: Rationale is that some clearing systems use BIC as inditifiers. Screen as exact match against lists of BICs of sanctioned Entities (possibly
enriched by List supplier)Embargo: exact match of BIC country (position 5-6) against embargo data
Others: Screen against lists of sanctioned Member Identification codes (own or sourced from List supplier)

EXACT

Entities: expand LEI into full name and match against Entities (fuzzy)
LEI: Screen against LEIs in sanctioned Entities
Embargo: if possible identify geographical or LOU (Local Operating Unit) from LEI and match Embargo Data

RA

FUZZY

Entities: Screen agains names of entities on lists
Embargo: Rationale is to detect possible connection with sanctioned countries if no other geograpical information is supplied
BIC: Rationale is to detect cases where a BIC is used in <Nm> rather than <AnyBIC>

YES

YES

RA

YES

YES

YES

text{1,140}

YES[0..1]

text{1,70}

RA

RA

FUZZY

Embargo: Rationale is to detect possible connection with sanctioned countries if no other geograpical information is supplied<SubDept>[0..1]

text{1,70}

RA

RA

FUZZY

Embargo: Rationale is to detect possible connection with sanctioned countries if no other geograpical information is supplied

Street Name

<StrtNm>[0..1]

text{1,70}

Building Number<BldgNb>[0..1]

text{1,16}

Building Name

<BldgNm>[0..1]

text{1,35}

Floor

<Flr>

[0..1]

text{1,70}

Post Box<PstBx>[0..1]

text{1,16}

Room<Room>[0..1]

text{1,70}

Post Code<PstCd>[0..1]

text{1,16}

RA

RA

EXACT

Embargo: Rationale is to detect possible connection with sanction programmes when it targets a specific region, not a country

Town Name<TwnNm>[0..1]

text{1,35}

YES

YES

FUZZY

Embargo: Rationale is to detect possible connection with sanctioned countries

Town Location Name

<TwnLctnNm>[0..1]

text{1,35}

YES

YES

FUZZY

Embargo: Rationale is to detect possible connection with sanctioned countries

District Name

<DstrctNm>[0..1]

text{1,35}

YES

YES

FUZZY

Embargo: Rationale is to detect possible connection with sanctioned countries

Country Sub Division<CtrySubDvsn>[0..1]

text{1,35}

YES

YES

FUZZY

Embargo: Rationale is to detect possible connection with sanctioned countries

Country<Ctry>[0..1]

text [A-Z]{2,2}

YES

YES

EXACT

Embargo: exact match of ISO 2 country code against embargo data

Address Line

<AdrLine>[0..7]

text{1,70}

YES

YES

FUZZY

Embargo: Rationale is to detect possible connection with sanctioned countries
Individuals /Entities: Rationale is to detect sanctioned parties in case part of the name appears in the adress line when using MT/MX translation tools

RA

RA

RA

YES

Table 14
Screening Debtor Agent (Financial
Institution Identification) in apacs.008 message

Guiding principles for screening ISO 20022 payments

27

Legal Notice

Disclaimer
This publication seeks to document the market
practices for screening ISO 20022 messages. It was
created in consultation and based on the feedback
of a group of SWIFT customers representing a large
portion of SWIFT’s traffic. As a mere informative
publication, it is not designed to provide any
recommendation or advice to the recipient, and should
not be used as such. Recipients remain solely and fully
responsible for all decisions based, in full or in part, on
the information contained in the document, and for all
consequences resulting from such decisions. SWIFT
disclaims all liability with regard to such decisions andtheir consequences. The information in this document
may change from time to time. You must always referto the latest available version.
Translations
The English version of SWIFT documentation is the
only official and binding version.
Trademarks
SWIFT is the trade name of S.W.I.F.T. SC. The following
are registered trademarks of SWIFT:
3SKey, Innotribe, MyStandards, Sibos, SWIFT,SWIFTNet, SWIFT Institute, the Standards Forumlogo, the SWIFT logo, SWIFT gpi with logo, the SWIFT
gpi logo, and UETR. Other product, service,or company names in this publication are trade names,
trademarks, or registered trademarks of
their respective owners.
Copyright
SWIFT © 2021. All rights reserved.