Skip to main content
The Signicat Blog
Sven Richard Samdal

SMB and Online Channels @ Signicat

Three steps to AML compliance using APIs – with code examples

Is your company subject to working with Anti-Money Laundering (AML) compliance? As a developer, navigating the world of AML compliance can be daunting. This may not be your specialist field, yet you are still required to implement code to ensure your company meets the required regulations. To simplify this process, we’ve broken down how Signicat’s APIs can be used towards keeping your business safe with helpful code examples to ease implementation.

A quick introduction to money laundering and AML compliance

Put simply, money laundering is the action of using proceeds obtained illegally from criminal acts and either concealing or disguising the money, who owns it or it’s illegal origins. For criminals to benefit from the illegal proceeds without arousing suspicion, the proceeds must be incorporated into the legal economy. It is not uncommon for money laundering to occur with the help of otherwise law-abiding friends, family or business associates.

AML and EU directives

To keep society safe from money laundering, businesses have a responsibility to ensure they are AML compliant. To help them do this, EU Anti-Money Laundering Directives (AMLD) have been put in place by the European Parliament, which are to be implemented by Member States as part of their domestic legislation.

The purpose of the directives is to ensure that the economic system and society are protected from money laundering or terrorist financing. A core part of these measures is the obligation to report suspicion of money laundering to local authorities and Financial Intelligence Units (FIUs).

Who is subject to AML reporting obligations?

Companies and individuals who are subject to mandatory reporting obligations are required by European regulations and local laws to collect and store certain information about their customers. This typically applies to anyone who works with money, including banks, credit and financial institutions, e-money companies, lottery and gaming companies, insurance companies, investment funds, payment companies, and crypto exchanges. It also applies to auditors, lawyers, accountants, and real estate agents.

Companies with reporting obligations are required to report any suspicion of money laundering to the authorities. In practice, this means that you need to be aware of the risk factors when establishing a customer relationship and understanding the obligation to monitor customers for as long as the business relationship continues.

KYC and CDD

Working with AML compliance means that you will encounter many acronyms, such as KYC, CDD, PEP and UBO. Know Your Customer (KYC) is one of the most important measures for preventing and uncovering whether financial systems are being misused for money laundering or financing terrorism. This includes identifying and verifying your customers’ identity, outlining what services and products they use within the reporting obligation, and detailing the scope of the customer relationship.

In practice, KYC involves collecting and analysing information about your customers. This is referred to as Customer Due Diligence (CDD). If the customer does not meet all the requirements during the due diligence process, then you should not enter into that customer relationship.

CDD in Norway

The examples used throughout this post are from Norway. In Norway, national regulations state that the duty to report should, among other things, carry out CDD when establishing customer relationships. When a customer is a natural person, the following information must be collected:

  • Name
  • National identity number, or other unique identity code (for those without a Norwegian national ID, date and place of birth, gender and citizenship status are required)
  • Address

In addition, documentation is required to show evidence of:

  • The Ultimate Beneficial Owner (UBO);
  • Whether the customer, persons acting on their behalf, or the UBO are Politically Exposed Persons (PEP);
  • The customer relationship purpose and intended nature.

The Norwegian Anti-Money Laundering Act allows customer relationships to be established either through physical attendance or without the customer being physically present, provided further measures have been implemented according to the act, and with the use of an electronic ID (eID).

Norwegian BankID

BankID is Norway’s most used electronic ID. It meets the legal requirements for carrying out identification checks and creating legally binding electronic signatures. Norwegian BankID is used by all Norwegian bank and any business that wants a secure and easy way to verify customers online.

When users identify themselves or electronically sign documents using BankID, the company will receive confirmation of their name and national identity number. This can then be used to obtain further information about the customer, such as their address from the National Population Register. We will come back to this later, but the bottom line is that when an identity is verified using electronic ID, we can programmatically assign multiple identity attributes from other sources to that customer.


How can APIs help with compliance of AML Directives?

We have established that AML compliance means Knowing Your Customer and carrying out CDD to confirm a customer's identity and obtain information such as name, national identity number, address, PEP and sanction status, and when the customer relationship was established. So how do we collect this information in the form of structured data?

APIs are the perfect tool to collect structured data efficiently, and they can easily be tailored to suit different user interfaces. Signicat’s APIs make it simple to obtain the relevant information needed to conduct CDD, meaning you can effectively comply with the legal requirements of the AML directives. Let's take a closer look at how this can happen in practice using a three-step process.

3 steps to AML compliance using APIs - with code examples

  1. Completing a KYC form
  2. Authenticating the customer using Authentication API
  3. Enriching the identity data using the Information Services API


1. Completing a KYC form

KYC reporting obligations for digital customer onboarding typically start with the new customer completing a KYC form on the website of the company they are onboarding with. Expect forms to vary in length and complexity, depending on the type of business and products in question. The forms will often ask for information the company cannot find on its own, such as email and mobile number, as well as the purpose and intended nature of the customer relationship. The KYC forms can be pre populated with data that can be retrieved from registers, and this is where APIs play an important role. Alternatively, the customer may be required to fill in the information manually, which will then be checked against risk and identity data sources. 

2. Authenticating the customer

Once the KYC form is complete, the next step is often to authenticate the customer. This can be done by either using a simple digital identification process (eID) or by using an electronic signature. When signing with an electronic ID e.g. BankID in Norway, this provides secure identification. However, the advantage of using electronic signing, rather than an eID is that a signed KYC form can act as a self-contained evidence package for any reviewing authorities. One smart solution is to convert your KYC from into PDF format and ask your customer to sign it with an eID. This will provide you with a time-stamped and sealed document (PadES) containing both the KYC data and the identity attributes from the BankID, such as name and national identity number. If you want a secure way to store and document data, Signicat also offers a Digital Evidence Management solution.

Implementing an eID or signing process is very easy if you have some basic coding knowledge. If you're a developer, you can easily create a free test account. You can also find ready-made code samples on the Signicat developer pages:


Authentication using an eID

While you can verify the identity by having the user sign the KYC form, this example will focus on authentication and show the simplicity of gathering information using an eID. The example shown here uses Norwegian BankID.

A simple authentication flow with Signicat's Express APIs requires sending a POST call against an endpoint called “Create session”. In the request to the API, you can specify how the authentication session should work, e.g.

      { 
    "flow":"redirect", 
    "allowedProviders":["no_bankid_mobile, no_bankid_netcentric"], 
    "include":["name","nin"], 
    "redirectSettings": 
{ 
        "successUrl":"https://signicat.com#success", 
        "abortUrl":"https://signicat.com#abort", 
        "errorUrl":"https://signicat.com#error" 
    } 
}

The above structure is called a ‘request body’. It instructs the API to take the user to an authentication page - this flow is called “redirect”. Next "allowedProviders" allows the user to choose between BankID on mobile, or on web (using a one-time code). We retrieve the name (“name”) and national identity number ("nin"), then specify which landing page the end user should be sent to after authentication, depending on whether the authentication was:

  • Successful ("successUrl")
  • The user interrupted the session ("abortUrl")
  • An error was made ("errorUrl")

For the end user, they will be prompted to log in with their BankId as shown below:

When the authentication session is successful, the response from BankID is retrieved using a new call to the "Retrieve session" endpoint. The following is returned from the API (to keep it simple, we have omitted some information and metadata here):

      { 
"status": "success", 
"created": "2022-05-24T21:31:00Z", 
"expires": "2022-05-24T21:41:00Z", 
"provider": "no_bankid_mobile", 
"identity":  
{ 
"providerId": "9578-6000-4-48855", 
"fullName": "John Doe", 
"firstName": "John", 
"lastName": "Doe", 
"dateOfBirth": "1980-01-01", 
"of":  "01018012345" 
} 
}

With the help of BankID, we have now managed to confirm the name ("John Doe") and the national identity number of the user. This information can then, for example, be passed onto a case management system or CRM system.


3. Enriching the identity data

The basic identity information collected in step two can be enriched by obtaining additional information about the customer from other sources, such as their address, and PEP (Politically Exposed Persons) and sanction status. This is done using a Information Services API solution.

Having already obtained the name and national identity number, this allows the address to be retrieved by making a call against Signicat’s "Information API", where we specify the National Population Register as the source.

The API makes a GET call, where we send the identity of the person we want to retrieve information about, and specify what information we want to retrieve about them. Our “Basic Info” endpoint will then return the address and additional information, such as registered name and nationality. The GET call looks like this:

https://api.signicat.io/information/countries/NO/persons/?identityNumber=01018012345 

The national identity number retrieved from the BankID is used in the call to the "Information API". As this is a unique identifier, it isn't necessary to submit any other information.

Note, access to data sources based only on national identity numbers in the Norwegian National Population Register require certain permissions. A person’s name and date of birth can be submitted instead if the national identity number is unknown, though this is not as secure an option as two people can share the same name and date of birth.

To fetch data from the National Population Registry, it should be specified as the preferred source in the API request. This is done by adding "source" as a parameter in the API call. In this case, use the "Modernized Population Register" and specify ‘no-freg’ as the source.

The response from the Information API confirms that John Doe was born on January 1, 1980. January 1980. He is a Norwegian citizen, born in Tønsberg, but he has a postal and residential address in Tistelvegen 207, 7033 Trondhem. 

      { 
  "names": [ 
    { 
      "isActive": true, 
      "startDate": "1997-03-04T12:30:00.000Z", 
      "endDate": null, 
      "status": "all", 
      "full": "John Due", 
      "first": "John", 
      "last": "Doe", 
      "middle": "null" 
    } 
  ], 
  "birth": { 
    "location": "TØNSBERG", 
    "monthOfBirth": "March", 
    "yearOfBirth": "1980", 
    "dateOfBirth": "1980-01-01", 
    "country": {
      "alpha2": "NO", 
      "alpha3": "NOR", 
      "numeric": "578" 
    } 
  }, 
  "nationalities": [ 
    { 
      "isActive": true, 
      "country": { 
        "alpha2": "NO", 
        "alpha3": "NOR", 
        "numeric": "578" 
      }, 
      "startDate": "1997-03-04T12:30:00.000Z", 
      "endDate": null 
    } 
  ], 
  "citizenships": null, 
  "permanentAddresses": [ 
    { 
      "isActive": true, 
      "isConfidential": true, 
      "startDate": "2018-08-02T12:30:00.000Z", 
      "endDate": null, 
      "addressLines": null, 
      "street": "Tistelvegen 207", 
      "postalCode": "7033", 
      "city": "TRONDHEIM", 
      "country": { 
        "alpha2": "NO", 
        "alpha3": "NOR", 
        "numeric": "578" 
      } 
    } 
  ], 
  "postalAddresses": [ 
    { 
      "isActive": true, 
      "isConfidential": true, 
      "startDate": "2018-08-02T12:30:00.000Z", 
      "endDate": null, 
      "addressLines": null, 
      "street": "Tistelvegen 207", 
      "postalCode": "7033", 
      "city": "TRONDHEIM", 
      "country": { 
        "alpha2": "NO", 
        "alpha3": "NOR", 
        "numeric": "578" 
      } 
    } 
  ], 
  "foreignAddresses": [], 
  "metadata": { 
    "sources": [ 
      "no-freg" 
    ], 
    "urls": [], 
    "lastChanged": null,
    "rawJson": null 
  } 
}

The name, national identity number, address and nationality of our customer are now confirmed.

PEP and Sanctions Lists

The next step is to check the customer against PEP and sanctions lists. A Politically Exposed Person (PEP) is someone who holds a prominent public position and thus poses a higher risk to being a target of bribery or corruption. Relatives and Close Associates (RCA) are also considered PEPs. It is important to be aware of a customer’s PEP status because PEPs should be subject to enhanced customer control and a more thorough risk assessment. Though the term refers to a ‘politically’ exposed person by law, it extends to non-political people who hold senior or executive positions making them susceptible to the same corruption and bribery as politicians.

Sanctions lists are lists created by national or international governments to impose commercial or financial penalties and restrictions on individuals, groups, or even entire countries. Sanctions are adopted by the UN Security Council, the EU or individual countries, as part of their security or foreign policy.

To ensure compliance with these restrictions, it's important to check that your customers aren't subject to any sanctions. Sanctions will often involve a ban on entering into agreements or trading with the sanctioned individual. It’s important to note that the AML Directives and the sanctions regulations are two different regulations. The purpose behind the sanctions regulations is to act as a broader political and economic instrument, which means that the action rules do not apply only to reporting obligations pursuant to the Money Laundering Act.

PEP and Sanction Lists API

Through the Signicat Information API, you can check the following standard sanction lists:

  • EU consolidated list of persons, groups and entities subject to EU economic sanctions
  • UN consolidated list
  • OFAC specially designated citizens
  • HM Treasury - consolidated list of financial sanctions
  • Local national sanctions lists – activated on request

Through the Signicat Information API, you can check the following PEP lists:

  • Acuris C6 Global PEP-list
  • PEP Edge

Let’s use the Information API to check if our customer "John Doe" is politically exposed or on a sanctions list. The GET call is used towards the "Screening" endpoint, by submitting the name and date of birth.

https://api.signicat.io/information/persons/screening?listType=pep,sanction&dateOfBirth=010180&name=John Doe

This provides the name and date of birth retrieved from the BankID, which is verified by the National Population Register. Here’s an example of what the API response might look like: 

      "data": [ 
{ 
"entityType": "organization", 
"listType": "sanction", 
"matchStrength": { 
"score": 20, 
"certainty": "low" 
}, 
"sourceName": "SCREENING_SOURCE", 
"name": { 
"status": "partial", 
"full": "OrgName AB", 
"first": null, 
"last": null, 
"middle": null 
}, 
"gender": "unknown", 
"aliases": [ 
{ 
"status": "partial", 
"full": "OrgName AB", 
"first": null, 
"last": null, 
"middle": null 
} 
], 
"associates": [ ], 
"datesOfBirth": [ ], 
"addresses": [ 
{ 
"street": "Hålebäcksvägen 7", 
"postalCode": "79026", 
"city": "ENVIKEN", 
"country": { 
"alpha2": "SE", 
'alpha3': 'SWE', 
"numeric": "752" 
} 
} 
], 
"comments": [ ], 
"functions": [ ], 
"media": [

AML compliance across Europe

Money laundering regulations are quite similar across many European countries because they follow the same EU directive, though there may also be local differences. Signicat's APIs are designed to support multiple eIDs and cross-country data and identitysources, and there is currently support for over 30 electronic IDs. For example, the Information API can easily retrieve an address from the Central Person Register (CPR) in Denmark, instead of the Norwegian Population Register. This can be done by simply specifying a specific parameter in the API.

When it comes to screening, the same PEP and sanctions lists usually apply across several countries. This means that by integrating Signicat APIs, you can access ID, signature and data and identity sources services in several different countries via one technical platform, making it for your business to enter new countries.

Not all countries have a well-established e-ID infrastructure like Norway, but both digital maturity and usage are on the rise in other less digitised countries. If you need to digital identity a customer who does not have access to an e-ID, you can use an ID document verification solution instead. This is known as Electronic Identity Verification (e-IDV). This solution uses a smartphone or webcam to take a picture or read the machine-readable zone (MRZ) fields in a passport, either via optics or the chip.

This allows identity attributes to be extracted from the identity card. Using NFC to read the data chip on the ID card means a high-resolution version of the person’s image can be retrieved, which can then be used in a "liveness check". This is where you verify that the owner of the ID card is the person who is trying to enter into the customer relationship. Often, the customer will be asked to record a short video clip where they smile and move their head to verify that no mask or other type of counterfeiting technique is used. Signicat can also help with onboarding customers through e-IDV technology.

Sources