Implementation Guide

This Implementation Guide is intended to help you with the implementation of the sanctions.io API Version 2.0 and higher.

An Intro to Sanctions Compliance

What are Sanctions and Sanctions Screening?

Financial sanctions are implemented by governments around the globe to restrict or prohibit trade with foreign and domestic targets involved in illegal or undesired activities. Sanctions may be leveled against territories, individuals, or entities, as well as against any countries, individuals, or entities acting on behalf of others that are engaged in criminal activities. Sanctions are often backed by civil and criminal penalties. 
Sanctions screening is a control designed to disrupt financial crime and sanctions risk through comparing data sourced from an organization's operations, including customer or other business partners and transactional records, against global sanctions lists containing names and other indicators of sanctioned parties or locations to detect similarities to determine whether a possible match exists. 
Organizations will typically utilize two main screening controls to achieve their risk reduction objectives:
a) Transactional screening that seeks to identify transactions that involve targeted individuals, organizations, or entities;
b) Customer / Name screening to identify targeted individuals, organizations, or entities during the onboarding or other crucial stages of the customer relationship.

The complex Landscape of Sanctions 

Sanctions screening may sound deceptively simple, but in reality, determining a “true match” is complex and deals with multiple variables, including international languages, cultures, spelling, acronyms, aliases, and technological limitations including varying algorithms, match rules, and workflows. Accuracy is influenced by the type and availability of data, the inherent sanctions risks to which the organization and its products/services/customers may be exposed, and the third-party sanctions screening solution deployed. 
The nature of Sanctions also adds to the complexity. Unlike economic embargoes, which prohibit all activity and transactions involving a specific country, list-based or smart sanctions target particular persons, entities, and organizations rather than a specific regime or country. Secondary sanctions target third-party actors doing business with specific regimes, organizations, persons, or entities. (A good example of secondary sanctions includes many Ukraine-related programs, which target Russia’s financial and energy sectors specifically). This means that customers who are not on a sanctions list but have a relationship with a sanctioned entity could present a potential risk for the organization in question. 
Other factors to consider:
There is a push particularly in Western nations to consider sanctions for a wider range of concerns, including human rights violations and cyber-attacks; 
  • Sanctions regimes may include sectoral or national embargoes;
  • Sanctions evasion techniques such as the use of Virtual Assets are becoming more sophisticated;
  • A rapidly changing geopolitical environment makes it harder for organizations to meet their sanctions obligations.
  • Many legacy screening platforms are still in use, which is both cumbersome and prone to large amounts of false positives.
For more information on Sanctions Compliance please refer to the following resources: 

Setting up your Screening Process

Please also see our technical API documentation.
Before starting with the integration it is essential to understand how the search, our name matching technology, and the confidence scoring model work. Please take some time to read through this and reach out to our support team if you have any questions. Getting this right is very important for a reliable screening process.

Preparing and Streamlining your Data 

Often the lack of data quality, integrity, or completeness is the reason sanction screening systems fail or suffer from poor performance. Companies need to compile and clean their KYC (Know Your Customer) information to avoid producing a large number of false positives and to avoid the possibility of failing to detect sanctioned entities during the screening process. 
Data sources may be distributed across IT systems and must be mapped and identified to obtain a more holistic view of the customer base. If possible, all data sources should be linked and integrated and be subject to the same quality standards by extracting, enriching, and loading the information to a single platform.
Data Points to consider for your Sanctions Screening process:
Entities Individuals
Name of the organization as registered Full Name (First, Middle, Last name)
Address Date of Birth
Tax ID Country of Birth, Nationality, Citizenship
Full name, Country of Birth, Date of Birth of all UBOs (Ultimate Beneficial Owners) Address, Passport ID

Defining the relevant Sanctions Lists for your Business

Businesses need to consider the relevant sanctioning bodies active in the countries they operate in, the territories in which they and their partnerships and alliances trade, and the currencies they are operating in.
Examples for some of the most relevant Sanctions lists for businesses operating in the US and Europe:
  • The HM Treasury Sanctions List applies to all individuals and legal entities within or who undertake activities within the United Kingdom, as well as all UK nationals and legal entities established under UK law. It’s enforced and overseen by OFSI (the Office for Financial Sanctions Implementation).
  • The EU Consolidated List of Sanctions applies to all EU citizens or corporate entities constituted in a member state and overseen by the EU Council.
  • The OFAC Sanctions List applies to all US citizens and corporate entities constituted in the US, as well as any entity that either trades in US dollars, US goods, or US components or that has a US parent or affiliate. Its regulatory body is the US Office of Foreign Assets Control (OFAC).
  • The UN Sanctions list applies to all UN Nation-states and is overseen by the UN Council. 
In addition to the above, there is a wide number of additional, country-specific regulatory bodies you might need to take into consideration when defining your Sanctions screening process. Depending on your business exposure, this task can be quite challenging. The following resource might be helpful:

The Problem of Name Matching

Name Matching is the real "hard nut to crack" in AML and Sanctions screening. While different Fuzzy Algorithms can help with some of the real-world challenges like typos, incomplete strings etc. some issues like transliterations of names, nicknames, missing name components etc. can't be mitigated with any fuzzy algorithm. The usual approach to mitigate these problems is that searches will be (under)defined very wide resulting in an overload of false positives or, even worse, false negatives. 
The following examples are real-world matching challenges. sanctions.io’s name matching technology solves these challenges by blending machine learning with traditional name matching techniques, such as name lists, common keys, and rules, to determine an overall matching score. 

Supported languages

Supported writing systems and transliteration standards

More information on Name Matching Technologies

Data Points for your Screening Process

There is no ‘one fits all’ balance between under-defining (many false positives) and over-defining (possible false negatives) the search as this largely depends on the data quality of your business partner data as well of the specific Sanctions List and also the 'risk appetite', exposure to high-risk customers/countries, and the compliance resources any organization has. 

Screening for Individuals

For Individuals, a good approach for example is to start with the Full Name and the Date of Birth (DOB) or Year of Birth (YOB for a ‘wider’ approach) in your search request. Usually, these two data points are sufficient and lead to good results with our smart matching technology. Including additional data points like Country of Birth, Passport IDs and/or Addresses in your search request can help reduce further the number of false positives.  (If you use any of the country fields please make sure to use the country information in ISO 3166-1 alpha-2 format).

Screening for Entities

A recommendable approach for Entity screening is to use the Name of the Organization along with the Country field ( ISO 3166-1 alpha-2 format). This will usually lead to good results and with our name matching algorithm you don't need to strip the organization's name of legal forms like LLC, INC etc. 

Screening for Vessels, Aircraft, and Crypto Wallet Addresses

Our database also contains vessel/aircraft names and IDs as well as Crypto Wallet Addresses which can be searched for in the respective fields. 
The above-discussed screening setups should be a good starting point for most organizations. The performance of this screening setup should continuously be analyzed and fine-tuned over time.

Screening Interval and Trigger Events

It’s recommended that screening takes place when establishing new relationships (onboarding), followed by regular screening either upon trigger events (transactions) and/or at predetermined intervals (daily, weekly, monthly). 
Transaction screening should be performed in such a way that the transaction may be stopped before a violation occurs.

Archiving and Case Management

Generally, it is recommendable to archive all your search requests for future audits. Our API response contains all the search parameters that were used for the search and so delivers all data necessary for a comprehensive archiving and auditable process.
For managing potential matches we recommend using either a ticketing system (such as Zendesk etc.) or, for a simpler workflow, recording all matches in an Excel or Google sheet with an email notification to the respective compliance team/manager. 
This whole workflow can also be set up without any coding involved, using no-/ or low-code tools like Zapier or Integromat
For a very simple workflow example using only low/no-code tools see our blog post on How to integrate our API with any CRM system.

Handling Matches

It’s important to note that an alert that is generated during screening, indicating a match between a customer or business partner and a record on a sanctions list, is not necessarily an indication of a sanctions risk. It needs to be verified, confirmed, or discounted using additional information to determine whether the match is true or a false positive. 
Manually review all of the client identity information you hold against the information within the sanctions list. You may also wish to approach your client for additional information. 
If the individual or entity matches all of the information on the list, it is likely a positive match and needs to be reported to your internal compliance team and/or you need to file a Suspicious Activity Report (SAR). All transactions with this client or business partner should be suspended. 
If you are confident that the match is a false positive, you may wish to whitelist the client’s name within your systems to avoid future matches.
For more information please refer to the FinCen Guide on filing SARs.

Testing your Screening Setup

After you have set up your Screening Process and defined the Watchlists you want to consider for your screening, it's advisable to test your approach. 
For your technical testing, you can use our Sandbox environment. For your first integration test, we are also happy to provide a temporary production API key so you can test your approach with actual Sanctions data before going live.
If you need any help during the Implementation please don't hesitate to reach out to our Customer Support Team. We are always happy to help.