Skip to main content

Sanctions lists

Fraugster provides anti-money laundering risk management via a partnership with Elucidate. With a single API integration, you benefit from financial risk management provided by Fraugster, and sanctions/PEP lists checks provided by Elucidate. Elucidate use their own data alongside public domain and proprietary data to run over 1200 discreet tests.

You configure which lists need to participate in checks when you opt in for this feature. If a user is found on a list, the transaction is marked accordingly, and you can view the details of the check on the Transaction page. You can also update or reconfigure the sanctions lists any time.

Response example

"fraugster_approved": 0,
"frg_trans_id": "abc01f6ccc8a5832a7871fdb14be1211",
"is_liable": false,
"liability_reason": "declined",
"score": 0.92,
"validation": {
"ok": true
"sanctions_lists": {
"hit": true,
"hits": [{ "list_name": "OFAC" }, { "list_name": "UN" }]

Here's an overview of the sanctions_lists field and its components, as well as each sanction list in detail.

hitAn enum that takes the following values:
  • true: The customer was found on one or more sanctions lists.
  • false: The customer was not found on any sanctions lists.
  • error: We sent a request to the Elucidate API and the sanctions list check returned an error.
  • timeout: The sanctions lists check timed out.
hitsAn enum that takes the following values. These sources are screened against on a daily basis.
  • OFAC: Office of Foreign Assets Control, US
  • SECO: State Secretariat for Economic Affairs, Switzerland
  • HMT: UK Treasury
  • METI: Ministry of Economy, Trade and Industry, Japan
  • DFAT: Department of Foreign Affairs and Trade, Australia
  • EU: European Union
  • UN: United Nations
  • PEP: Politically exposed persons

Data requirements

To enable a check against any of the lists, you must provide at least one of the following datapoints in your API request:

  • cc_cardholder – the full name of the credit card holder
  • cust_name – the full name of the customer
  • cust_ship_name – the full name of the customer on the shipping address
  • cust_bill_name – the full name of the customer on the billing address

If these datapoints are missing in your API request, we don't send a request to the Elucidate API, hence the field sanctions_lists is going to be absent all together in your Fraugster API response.

Additionally, you may want to send address details to accompany the name fields. Address details are not mandatory by default, but they give you a better idea of the accuracy of the check if there is a match. These address fields may be sent for each name entity:

Dashboard sectionNameCorresponding address information
Payment detailscc_cardholdern/a
Customer detailscust_name
  • acct_ad_line1
  • acct_ad_line2
  • acct_ad_city
  • acct_ad_state
  • acct_ad_zip
Shipping detailsship_ad_name
  • ship_ad_line1
  • ship_ad_line2
  • ship_ad_line3
  • ship_ad_city
  • ship_ad_state
  • ship_ad_zip
Billing detailsbill_ad_name
  • bill_ad_line1
  • bill_ad_line2
  • bill_ad_line3
  • bill_ad_city
  • bill_ad_state
  • bill_ad_zip

Here's how we proceed with the check when we have the data:

How does a match happen?

To be considered a match, the values of the mandatory datapoints must match exactly the record in the sanctions list. At the moment, it's mandatory to send the full name of the customer in at least one of these datapoints: cc_cardholder, cust_name, cust_ship_name, or cust_bill_name.

Address information, if available, participates in the check. By default, it isn't mandatory, i.e. if the name matches a record and the address doesn't (or is absent), the check returns a match.

You can decide to enforce address information in your sanctions lists checks. This scenario is considered a strict match: the check returns a match only if both the name and the address match the record.

How does Fraugster treat address information?

You send address information in the form of specific datapoints – see Data requirements for details. You can choose to send all of the corresponding datapoints or only a few.

If the address is provided, it's always checked – regardless of whether you opted in for strict matching. But only in the case of strict matching does it influence the final match.

The address string that participates in the check is a space-separated concatenation of the received datapoints. We remove commas, hyphens, etc. on our end and prepare the input string before the check. Here are a few examples of how the input string may look like:

  • 820 MainSt Bridgeport CT 06604
  • Bridgeport 06604
  • 10317
  • Charlottenstr 4 10969 Berlin

If you opted in for a strict match of the name and address, the input string must match part or all of the record string in order to be considered a match. For example, Bridgeport will match a record with the address 820 MainSt Bridgeport CT 06604.

Address abbreviations and alternative spelling of address components are treated as equivalent. Please check the list of address abbreviations that are considered during a check.

Further behavior to consider

  • If you decide to send several names in your API request, for example cc_cardholder and cust_ship_name, we perform a check on each of the names we receive, even if the name is identical in all cases.
  • Algorithm looks for specific parts of the address and disregards the order of occurrence in the string. For example, Torstr 42 Berlin is going to match Berlin 42 Torstr.