Developer Guide to Transaction Screening (with Code Samples) – Part 1

In this series of articles for developers and product teams, we will get our hands under the hood and explore every facet of the Screena API. We will share best screening practices for utmost performance with high-level control and agility.

Now, before diving into Screena API endpoints, let’s first walk through the different data elements within transactions most commonly relevant for screening.

Current Screening Practices

The guiding principles for screening published by SWIFT provide insights on the FIN MT 103 fields subject to screening according to market practices. Fields that the most banks screen include:

Party Fields

Bank Identification Fields

Narrative Fields

In line with the Wolfsberg guidance on sanctions screening, fields containing dates, amounts, charges, transaction references and codes are usually not subject to screening.

Building Match Queries

The core feature of any screening solution is to match and search named entities across 2 or more data objects – at least one being the source and another the target of the match query. Simply put, it means fields (i.e. business elements) within transactions shall be matched against list elements in the context of transaction screening.

More concretely, business elements within transactions are posted to Screena API under the query object sourceData. Those business elements are then matched against list elements stored within datasets, the label of which shall be declared under the query object targetData. To learn more about datasets: https://developer.screena.ai/#creating-datasets

The table below lists all the datasets available on Screena’s sandbox and populated with watchlist entities continuously published by government authorities or international organizations. Remember you can always try out Instant Search and manually search for an individual, an organization, or a vessel on any of these lists.

This code example executes a search of a party named PHILIPS MARK against the United Nations list.

At this point, it is important to highlight that Screena works as a zero-footprint screening agent. A zero-footprint agent means there is no personally identifiable information stored whatsoever when a screening query is posted to Screena. Source data is kept anonymous at all times as Screena encrypts data in transit, in compliance with AES-256 SHA 512.

Screena only logs and counts the number of API requests executed monthly for billing purposes. Those requests are uniquely identified through the attribute requestID contained in the JSON header envelope. To learn more about headers: https://developer.screena.ai/#header

About Matching Algorithms

We might be stating the obvious but posting source and target data alone is not enough to run a match query. Matching named entities requires algorithms to determine how data should be matched.

In this regard, we distinguish name-matching algorithms from secondary attributes-matching algorithms. In the next section, we will clarify the differences between names, and primary and secondary attributes.

Matching names requires a threshold value between 0 and 100%. This value helps to determine the point where it becomes highly probable that two names are the same.

As you will notice in the code examples provided in this article, it is not mandatory to specify a threshold value when building a match query. When the attribute threshold is omitted, Screena will use 60% as a default value. If you wish to work with a different threshold value, you will have to specify it in your query with this piece of code.

In addition to name matching, it is also possible to apply specific matching algorithms to secondary attributes. For example, this piece of code is used to match addresses with the same country.

Using secondary attributes-matching algorithms helps to automatically discard irrelevant matches (i.e. false positives) by leveraging more data points than names alone.

To learn more about matching algorithms: https://developer.screena.ai/#algorithms

Now that we have seen how the core elements of a screening query fit together, let’s deep dive into what types of elements can be matched as well as the attributes that define them.

Named-Entity Types and Attributes

A named entity is a real-world object, such as individuals, organizations, locations, vessels, etc., that can be denoted with a proper name and associated with an entity type.

Most of the named entities contain primary attributes and unique identifiers (i.e. information that can be searched for to create a hit), and secondary attributes (i.e. information that will be used to retain or discard a hit resulting from matching against primary attributes).

Technically speaking, named-entity objects can be nested inside other objects and used as secondary attributes. Typically, addresses, placesOfBirth, and nationalities are named entities belonging to the location type, all while constituting secondary attributes of an individual.

The attribute entityType has a high impact on the matching process. Explicitly associating the name of an entity with an entity type increases the accuracy of the matching. When entityType is provided within a match query along with the algorithm entityTypeAlgo set with the value “exact_match”, Screena will reject matches between entities with different entityType (e.g. individual vs vessel).

This code enforces a search with matching entity types.

Please note it is also possible to use the option exclude within entityTypeAlgo. In this case, Screena will exclude matches for specific entity types. It is especially helpful to prevent irrelevant matches when entityType can not be provided as it happens with FIN MT 103 messages.

This code executes a search excluding matches against vessels.

Now let’s quickly review the main types of named entities carried over transactions and their attributes used for screening against lists. For further definitions and additional informative attributes of named entities, check out our complete API documentation.

Individuals

This code builds an individual named object.

Organizations

This code builds an organization named object.

Vessels

This code builds a vessel named object.

BICs

Business Identifier Codes (BICs) are not explicitly a type of named entity like the previous types above. Rather, they are used by financial and non-financial institutions as an international identifier to facilitate the automated processing of information. For instance, BICs are the primary means of identification for financial institutions on the SWIFT network, where the core of international transactions is processed and contain a country code that is relevant for embargo screening.

Unlike other identifiers, BICs are global in nature which makes them particularly effective to identify matches against sanctioned organizations or discard potential hits resulting from matching names.

In accordance with the 2 methods commonly applied by the industry to screen a BIC, Screena allows the use of BIC codes to either substitute or complement name information. In other words, BIC codes can be either considered as an attribute of an organization (as they are declared in lists) or as a standalone entity attribute.

This code executes a search using bic as an entity attribute. This is the most effective and efficient method but requires lists that are enriched with BICs. When applying this method, the algorithm bicAlgo is also required within the match query.

The other method consists in converting the BIC into its name and address using a SWIFTRef product, then matching the name and address embedded within an organization named-entity against the lists. This method is the fallback option when a BIC is not provided, or when the lists are not enriched with BICs.

Narratives

Narratives are widely used in payment messages to provide a free-format description in addition to structured information (e.g., remittance information, instruction for next agent, instruction for creditor’s agent, regulatory reporting, etc).

Narratives are not a type of named entity per se. On the other hand, narratives can contain information about named entities, whatever their type. For this reason, it is important to ensure narrative fields within transactions are screened against all list elements, whether they are individuals, organizations, vessels, or countries subject to embargo.

Keep in mind that narratives cannot be used in conjunction with other attributes when building a match query in Screena. The field narrative must always be sent alone, independent of other data – field dataID excepted. As a consequence, when screening SWIFT messages, narrative and structured information shall be sent as two different queries.

This code executes a search using narrative.

Next Readings

This first article walked you through all the data elements within transactions relevant for screening. It also gave you best practices to increase the accuracy of matching depending on the nature and the quality of the data at stake.

Our next article will discuss some challenges faced when screening MT messages and free format fields, and how to overcome them. That’s followed up by an article on country-based screening.

Our remaining articles will provide some good practices for custom screening strategies.

To find out how Screena’s powerful name-matching and cloud infrastructure can transform your transaction screening strategy, get in touch with our sanctions compliance experts and immediately get 30-day free API access to Screena sandbox so you can see it for yourself.