Implementation Guide

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

1. 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. 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: 

2. Preparing and Streamlining your Business Partner 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


  • Full Name of the Organization as registered
  • Address of Headquarter
  • Tax ID
  • Full name, Country of Birth, Date of Birth / Year of Birth of all UBOs (Ultimate Beneficial Owners)


  • Full Name (First, Middle, Last Name)
  • Date of Birth or Year of Birth
  • Country of Birth, Nationality 
  • Citizenship(s) 
  • Address 
  • Passport ID 

3. Setting up your Screening Process

Please also see our technical API documentation.

Before starting with the integration it is very important 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 your screening process.

Our Name Matching Technology

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. 

Our 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 a match score. This score can also consider fuzzy matches in other fields (including address and date of birth). 

Supported languages

13 ways matches names

Supported writing systems and transliteration standards

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. Some of the most relevant Sanctions lists are for example:

  • 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. Please see here a list of all Sanctions and Watchlists available in

Data Points to use 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 each Sanctions List as well as the 'risk appetite', exposure to high-risk customers/countries, and the compliance resources any organization has.

Screening for Individuals

Generally, it is advisable to apply different approaches for Entities (Organizations) and 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. If you still get too many high-scored false positives you can include additional data points like Country of Birth, Passport IDs and/or Addresses in your search request. (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 (ISO 3166-1 alpha-2). This will usually lead to a good result and with our name matching algorithms 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 and the performance can then be analyzed over time and adjusted accordingly to the specific needs in any organization.

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

We recommend archiving all your search requests for future audits. Our API response also contains all the search parameters that were used for the search and hence delivers all data necessary for a comprehensive archiving 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 process can also be set up without any coding using 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 following resources:

4. 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.