EFI Data Protocols

For Financial Institutions, it is critical to maintain and increase correspondent banking relationships, as well as to manage financial crime risk effectively.

The EFI provides a number of enterprise solutions to enable more targeted and effective FinCrime risk management.

Critically, we enable our clients to understand and evidence FinCrime risk profiles, and to control the narrative around FinCrime risk with Correspondents, Regulators and other counterparties.

In this page you will find all necessary data protocols you will need to extract from your system in order for Elucidate to perform the Elucidate FinCrime Index assessment.

Download all sample package here

Change Log

Version Summary

Version	Date	Change
0.1	01.11.2018	Initial private version
0.2	15.11.2018	Added anonymisation mechanism
0.5	13.12.2018	Link samples to EFI version
0.6	01.10.2019	Improved transaction file
0.7	27.01.2020	Improved transaction file
0.8	26.02.2020	Improved customer data protocol
0.9	03.06.2020	Improved sanctions and transactions screening protocol
0.10	11.09.2020	New fields and types added
0.11	29.10.2020	Attribute details tables for all files and new fields and types and added
1.0	04.01.2021	Improved description of attributes and new data attributes added. Updates on Anonymisation, Security and Common Types
2.0	01.03.2023	Slimmed protocol to Wolfsberg CBDDQ, Transactions, Account Holder and Sanctions Screening. Removed Employee Data, Transaction Monitoring, Product Report, Affiliates Report, Vendors, Accounts, Account-Holder Ref and Watchlist Management. BIC fields renamed to *_fi_id to also accept ABA / CHIPS Uid.
2.1	13.05.2026	Added AI Readiness section: six-pillar maturity framework, technical artefacts per pillar, and the engagement model for data-extraction work. Bumped Wolfsberg CBDDQ reference to v1.4 (accepted: 1.3 or 1.4). Added ISO 4217 codes BYN / MRU / STN / VES / SLE / ZWG to the Currency pattern; discontinued codes kept for historical data. Synchronised the LegalEntityType tree diagram with the enum. No data-protocol changes — existing submissions are unaffected.
3.0	19.05.2026	Rebuilt the AI Readiness section around voluntary supplementary datasets — transactional data, customer data, control effectiveness — that institutions may provide to support an AI readiness assessment. Schema is not prescribed; it is derived with the institution during discovery. Added Regulatory Context sub-section linking to FCA (UK), EU AI Act / EBA / ECB, SR 11-7 / SR 26-02 (US), MAS, HKMA, OSFI and AUSTRAC. Added Agentic AI sub-section describing how Elucidate's agentic work — surfaced through Eli — consolidates the voluntary datasets without bespoke integration builds. Removed the six-pillar maturity framework, the per-pillar Elucidate-positioning content, "The Honest Part", and "We Help You Extract The Data" (source systems, extraction patterns, engagement model). The mandatory data protocol is unchanged — existing CSV / JSON submissions are unaffected.

Version 1.0 Changes

Section	Changes
Customer Data	Added the following two new data attributes: - account_suspended - account_suspended_date Improved description of the following data attributes: - isic_code - product_usage - source_of_wealth - source_of_funds - account_suspended - account_suspended_date
Customer Associated Parties	Added the following two new data attributes: - associated_countries - ultimate_beneficial_owner Improved description of the following data attributes: - account_number - entity_type - beneficial_owner_name - beneficial_owner_share_percentage - director_name - signatory_name - date_of_birth
Transactions	Improved description of the following data attributes: - transaction_id - incoming_intermediary_fi_bic - outgoing_intermediary_fi_bic
Employee Data	Added the following new data attribute: - contract_consultant Improved description of the following data attributes: - employee_outside_business_organisation
Employee Training & Conduct	Improved description of the following data attributes: - training_subject
Product Report	Updated title of data attributes from product_mapped_to_elucidate_standard_product_list to mapped_product Added the following new data attribute: - product_id
Sanctions Screening	Added the following two new data attributes: - alert_transaction_id - alert_list_name
Transaction Monitoring	Added the following new data attribute: - alert_list_entry_name
Affiliates Report	Added the following new data attribute: - affiliate_percent_ownership
Vendors	Added the following three new data attributes: - service_provided - vendor_id - vendor_address_country
Anonymisation	Improved the description to request an anonymisation data submission file each month with sample names anonymised and detail of the header fields required in a file
Security	Changed text for encryption of data to public instead of private key
Not Collected	Added not_collected string in the Common Types section to cover where data points are not available to be provided.

Version 1.2 Changes

Data protocol changes will be released on May 15th 2022 both on documentation and for new clients currently onboarding also on the platform. Existing clients will have individual timeline agreed with Customer Success Manager to switch to new formats until October 2022

Quick View

Old files v1.1	New files v1.2
Transactions	Transactions
Customers	Account Holder
Employee Data	Employee Data
Sanctions Screening	Sanctions Screening
Transaction Monitoring	Transaction Monitoring
Product Report	Product Report
Affiliates Report	Affiliates Report
Vendors	Vendors
Employee Training & Conduct
Customer Associated Parties
	Accounts
	Account-Holder Ref
	Watchlist Management

Detailed View

Old Files	New Files	Data Format Changes
Transactions	Transactions	No changes to data points
Customers and Customers Associated Parties	Accounts, Account Holder, and Account-Holder Ref	Splitting customer and customers associated file into Accounts, Account Holders, and Account-Holder Ref. Accounts will include: - account_number - cash_balance_amount - cash_balance_currency - account_open_date - account_close_date - account_close_reason - account_suspended - account_suspended_date - account_opening_type - branch_id - relationship_manager_employee_id - product_usage Account holders file will include: - account_holder_id - full_name - first_name - middle_names_patronmyic - last_name - date_of_birth - place_of_birth_city - place_of_birth_country - country_citizenship - document_present - address - address_country - address_postal_code - address_city - legal_entity_identifier - legal_entity_type - legal_form - isic_code - adverse_information_search - adverse_information_search_date - net_worth_amount - source_of_wealth - source_of_funds - initial_cdd_completion_date - last_cdd_review_date - system_risk_rating - pep_status - associate_pep_status - edd_triggered - branch_id - relationship_manager_employee_id - is_sanctioned - sanction_screening_date Account-Holder Ref will include: - account_holder_id - account_number - beneficial_owner_documentation - is_beneficial_owner - owner_share_percentage - is_director - is_signatory - ultimate_beneficial_owner We will require a parent and child account number to show the link between accounts where applicable. in instances where there is a parent and child account; account_number_parent would be the parent and account_number would be the child
Employee and Employee Training	Employee Data	Merged the Employee Training & Conduct file with the Employee file Added the following new data attribute: - employee_financial_crime_certification - employee_financial_crime_certification_date We will require 12 months of employee data When you select an employee breach, please ensure it includes the abc_breach_amount, abc_breach_currency & abc_breach_date This will be one line per employee. So if an employee has a 1, 2 or X amount of breaches, this should be input as - Breach 1 = abc_breach_amount 1, abc_breach_currency 1 & abc_breach_date 1 - Breach 2 = abc_breach_amount 2, abc_breach_currency 2 & abc_breach_date 2 - Breach 3 = abc_breach_amount 3, abc_breach_currency 3 & abc_breach_date 3 When you select an employee training, this should include the training_assessment, training_date and training_subject This will be one line per employee. So if an employee has a 1,2 or X amount of training, this should be input as - Training 1 = training_assessment, training_date 1and training_subject 1 - Training 2 = training_assessment 2, training_date 2 and training_subject 3 - Training 3 = training_assessment 3, training_date 3 and training_subject 3
Watchlist Management	Introduced a new data protocol on internal and external watchlists. This data protocol will require the following data attributes. The data points internal_list_dateofbirth_incorp and internal_list_fullname can be hashed and anonymised - external_list_fullname - external_watchlist_provider - internal_list_addition_datetime - internal_list_addition_reason - internal_list_dateofbirth_incorp - internal_list_deletion_datetime - internal_list_deletion_reason - internal_list_entity_type - internal_list_entry_country_location - internal_list_entry_id - internal_list_entry_source - internal_list_fullname
Product Report	Product Report	Added the following new data attribute: - new_product_release
Sanctions Screening	Sanctions Screening	Added the following new data attribute: - sanctions_screening_system - sanctions_screening_system_version
Transaction Monitoring	Transaction Monitoring	Added the following new data attribute: - account_regulator_filing - account_regulator_filing_date
Vendors	Vendors	No changes to data points
Affiliates Report	Affiliates Report	Added the following new data attribute: - revenue_percent_generated_per_affiliate - products_per_affiliate - new_product_release_list If you have any affiliates, please complete and send this data protocol as part of your monthly upload

Version 2.0 Changes

Data protocol changes will be released on May 15th 2023 both on documentation and for new clients currently onboarding also on the platform. Existing clients will have individual timeline agreed with Customer Success Manager to switch to new formats until October 2023

Quick View

Old files v1.2	New files v2.0
Transactions	Transactions
Account Holder	Account Holder
Sanctions Screening	Sanctions Screening
Employee Data
Transaction Monitoring
Product Report
Affiliates Report
Vendors
Accounts
Account-Holder Ref
Watchlist Management

Detailed View

Old Files	New Files	Data Format Changes
Transactions	Transactions	Transaction direction and branch id removed. BIC fields now renamed to id to support BIC, ABA, CHIPs Uid
Account Holder	Account Holder	Removed fields for customer ease
Sanctions Screening	Sanctions Screening	Removed fields for customer ease

Version 2.1 Changes

Released on 13 May 2026. Documentation-only release — no data-protocol changes; existing CSV / JSON submissions are unaffected.

Quick View

Section	Change
AI Readiness	New section describing the six-pillar AI-readiness maturity framework banks use to score their preparedness to deploy AI in regulated workflows, the concrete technical artefacts each pillar demands, what Elucidate ships against pillars 3 and 6 (governance + regulatory), and the engagement model for closing the data-extraction gap that blocks most institutions at pillar 1.
Wolfsberg CBDDQ	Reference bumped to v1.4 (current Wolfsberg publication). Accepted submission versions are now 1.3 or 1.4. Link updated to wolfsberg-group.org (old domain still 302s).
Currency	Added modern ISO 4217 codes: BYN (2016), MRU (2018), STN (2018), VES (2018), SLE (2022), ZWG (2024). Discontinued predecessors retained so historical transaction data still validates.
Legal Entity	Tree diagram synchronised with the enum (ngo_general, gov_intl_org, fi_bank, legal_type_other ...). No change to accepted values.
Security	API documentation link updated to its canonical path /api.
Pseudonymisation	Fixed mailto target to security@elucidate.co (display and target now match).

Detailed View — AI Readiness

Sub-section	What it covers
The Six Pillars	Overview table of the framework (Data, Infrastructure, Governance, Talent, Strategy and Operating Model, Regulatory and Compliance).
Data Readiness	Schema-first ingestion, semantic IDs, lineage, drift detection, boundary pseudonymisation. Cross-links to the existing protocol files as worked examples.
Infrastructure Readiness	Versioned APIs, structured logs, distributed tracing, idempotent ingestion, inference compute.
Governance Readiness	Model registry, model cards / Annex IV, AI policy, audit log schema with decision_id / model@version / input_hash, replay capability, bias controls, ISO 42001, SR 11-7.
Talent Readiness	Templates and runbooks Elucidate ships for in-house validators.
Strategy and Operating Model Readiness	Shadow-mode and canary deployment patterns for methodology cutover.
Regulatory and Compliance Readiness	Traceable / explainable / fair / reversible mapping table; EU AI Act and SR 11-7 references.
The Honest Part	Real blockers are data quality (pillar 1) and governance sign-off (pillars 3 + 6).
We Help You Extract The Data	Source-systems table (Temenos, Finastra, Mambu, NICE Actimize, World-Check, Trulioo, Snowflake, ...), extraction patterns (CDC, batch + SFTP, REST polling, message-bus, manual file drop) with pseudonymisation always running inside the bank boundary, and the discovery → build → handover engagement model.

Version 3.0 Changes

Released on 19 May 2026. The mandatory data protocol is unchanged — existing CSV / JSON submissions are unaffected. The AI Readiness section has been rebuilt around a list of voluntary supplementary datasets with no prescribed schema; an institution submits a subset by agreement during discovery.

Quick View

Section	Change
AI Readiness	Rewritten as a list of voluntary supplementary datasets — transactional data, customer data, control effectiveness — institutions may provide to support an AI readiness assessment. The previous six-pillar maturity framework, the per-pillar Elucidate-positioning content ("What Elucidate ships against this pillar"), "The Honest Part" and "We Help You Extract The Data" (source systems, extraction patterns, engagement model) are removed. Schema is not prescribed; only a stable record identifier and a timestamp per record are required, with the canonical schema derived collaboratively with the institution during discovery.
Regulatory Context	New sub-section of AI Readiness. Reference table for the supervisory frameworks shaping AI in regulated financial-crime workflows: FCA (UK), EU AI Act / EBA / ECB, Federal Reserve / OCC / FDIC (SR 11-7 + SR 26-02), MAS (Singapore), HKMA (Hong Kong), OSFI (Canada), AUSTRAC (Australia). Anchors the section on the FCA's outcomes-based stance and explains why a firm that can satisfy the FCA can, in practice, satisfy the more prescriptive regimes once the data and assurance layers are in place.
Agentic AI	New sub-section of AI Readiness. Describes how Elucidate's agentic work — surfaced through Eli, the autonomous compliance agent — consolidates the voluntary datasets across the institution's source systems without a multi-quarter integration build, ETL programme, or strategic data-platform deployment. Schema-neutral on the source side, schema-stable on the output side, with pseudonymisation applied at the boundary.

Detailed View — AI Readiness

Sub-section	What it covers
Preamble	The datasets are voluntary and sit outside the mandatory protocol. Schema is not prescribed and is derived with the institution during discovery. Boundary pseudonymisation applies as per Pseudonymisation. Includes a paragraph explaining why AI readiness is worth starting on now — the bottleneck for AI in regulated workflows is data availability, lineage and assurance rather than the model itself; beginning the work against data the institution already produces is low-cost, high-option-value, and compounds into the existing control environment before any AI is deployed.
Regulatory Context	First sub-section. Cross-jurisdictional reference table: FCA AI approach (UK), EU AI Act + EBA factsheet + ECB Supervisory Priority 2 (2026–28), SR 11-7 + SR 26-02 (US), MAS FEAT + AI Risk Management Toolkit / Project MindForge (Singapore), HKMA Fintech Promotion Blueprint + GenA.I. Sandbox++ (Hong Kong), OSFI Guideline B-13 / E-23 (Canada), AUSTRAC AI transparency statement + 2026 AML/CTF reform (Australia). Frames the FCA as the most useful single anchor because its outcomes-based stance forces the same evidence base that the more prescriptive regimes require.
Transactional Data	Unmonitored transactions; transaction monitoring escalation and investigation; payment stops and rejections; sanctions investigations; internal watchlists.
Customer Data	Customer rejections and exits; extended customer data (EDD narrative, source-of-wealth corroboration, adverse media outcomes, RM assessments, periodic-review depth indicators).
Control Effectiveness	Audit reports and audit results; QA reports and QA results; assurance results.
Agentic AI	The voluntary datasets are scattered across TM, screening, case management, GRC, warehouse and spreadsheets. Elucidate's agentic work — surfaced through Eli — reads from those systems in place, normalises and reconciles inside the bank boundary, and produces the consolidated output schema without a bespoke integration build or strategic data-platform deployment.

Removed in 3.0

Sub-section	Status
The Six Pillars / Data Readiness / Infrastructure Readiness / Governance Readiness / Talent Readiness / Strategy and Operating Model Readiness / Regulatory and Compliance Readiness	Removed. AI Readiness in this protocol is no longer framed as a maturity model.
The Honest Part	Removed.
We Help You Extract The Data	Removed. Engagement-model content lives outside this protocol.

Timeline

Data from the previous calendar month needs to be made available by the 10th of the current month.

Formats

We will accept data submissions in CSV, xls, xlsx or JSON formats. We accept ISO 20022 format.

For CSV file descriptions, the CSV Schema can be referenced for additional detail CSV Schema

For JSON file descriptions, the JSON Schema can be referenced for additional detail JSON Schema

You can submit the files individually or zip, rar or tar.gz

If you want to encrypt the files please check our security section

Prioritisation

The priority level assigned to each file type is based on the number of tests conducted on the data contained in each.

File name	Priority
Wolfsberg CBDDQ	1
Transactions	1
Account Holders	2
Sanctions Screening	2

In general, there are two modes of assessment:

• Portfolio assessment - where your institution is assessing your counterparties
• Self assessment - where you are performing an assessment of your institution

The following table provides details on which files should be provided, based on the mode of assessment and how the files should be loaded:

File name	Self assessment	Portfolio assessment
Wolfsberg CBDDQ**	x	x
Transactions*	x	x
Account Holders	x
Sanctions Screening*	x	x

* These files should contain the relevant FI portfolio data

** A completed Wolfsberg CBDDQ should be provided initially (A) and a new fully completed version anytime there are changes

Beyond the data protocol itself, the AI Readiness section below lists additional datasets — across transactional activity, customer lifecycle decisions, and control-effectiveness assurance — that institutions may voluntarily provide to support an AI readiness assessment. Schema is not prescribed for these datasets; it is derived in collaboration with the institution during discovery.

There are two types of file loading. The appropriate loading type is specified in the table below:

Institution Data

Wolfsberg CBDDQ

The Wolfsberg Group publishes the Correspondent Banking Due Diligence Questionnaire (CBDDQ) — currently at v1.4 — together with the supporting Completion Guidance, FAQs and Glossary.

The CBDDQ aims to set an enhanced and reasonable standard for cross-border and/or other higher risk Correspondent Banking Due Diligence, reducing to a minimum any additional data requirements, as per the Wolfsberg definition and current FATF Guidance.

It is also the Group’s expectation that the Group members will use the CBDDQ, in a phased approach, with all of their respondents. For more information about Wolfsberg CBDDQ go here.

Please note that CBDDQ versions 1.3 or 1.4 are acceptable for submission.

File Name

Files regarding the Wolfsberg CBDDQ should have the prefix wolfsberg_cbddq and the date for which it represents.

wolfsberg_cbddq_YYYYMMDD.xlsx

For example, a file with all the data from 2018 should be:

wolfsberg_cbddq_20181231.xlsx

If you plan to attach more documents referred in the Wolfsberg CBDDQ please do so using the same prefix.

Sample Package

Download sample package here

Account Holder

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "array",
  "items": {
    "$ref": "#/definitions/AccountHolder"
  },
  "efiVersion": "2.0",
  "definitions": {
    "AccountHolder": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "account_number":                             { "$ref": "#/definitions/nonEmptyString" },
        "full_name":                                  { "$ref": "#/definitions/nonEmptyString" },
        "account_holder_id":                          { "$ref": "#/definitions/nonEmptyString" },
        "date_of_birth":                              { "$ref": "#/definitions/Date" },
        "place_of_birth_country":                     { "$ref": "#/definitions/Country" },
        "country_citizenship":                        { "$ref": "#/definitions/Country" },
        "address":                                    { "$ref": "#/definitions/Address" },
        "address_country":                            { "$ref": "#/definitions/Country"},
        "legal_entity_type":                          { "$ref": "#/definitions/LegalEntityType" },
        "system_risk_rating":                         { "$ref": "#/definitions/SystemRiskRating" },
        "is_pep":                                     { "type": "boolean" },
        "edd_triggered":                              { "type": "boolean" },
        "is_sanctioned":                              { "type": "boolean" },
        "sanction_screening_date":                    { "$ref": "#/definitions/Date" }
      },
      "required": [
        "account_number",
        "account_holder_id",
        "full_name",
        "date_of_birth",
        "country_citizenship",
        "address",
        "address_country",
        "legal_entity_type",
        "system_risk_rating",
        "is_pep",
        "edd_triggered",
        "is_sanctioned",
        "sanction_screening_date"
      ],
      "title": "AccountHolder",
      "allOf": [{
        "if": {
          "properties": {
            "adverse_information_search": { "const": "true" }
          }
        },
        "then": {
          "properties": {
            "adverse_information_search_date": { "$ref": "#/definitions/MaybeDate" }
          }
        }
      }]
    },
    "Country": {
      "title": "Country",
      "description": "ISO 3166-1 alpha-2 country code",
      "type": "string",
      "pattern": "^(AF|AX|AL|DZ|AS|AD|AO|AI|AQ|AG|AR|AM|AW|AU|AT|AZ|BS|BH|BD|BB|BY|BE|BZ|BJ|BM|BT|BO|BQ|BA|BW|BV|BR|IO|BN|BG|BF|BI|KH|CM|CA|CV|KY|CF|TD|CL|CN|CX|CC|CO|KM|CG|CD|CK|CR|CI|HR|CU|CW|CY|CZ|DK|DJ|DM|DO|EC|EG|SV|GQ|ER|EE|ET|FK|FO|FJ|FI|FR|GF|PF|TF|GA|GM|GE|DE|GH|GI|GR|GL|GD|GP|GU|GT|GG|GN|GW|GY|HT|HM|VA|HN|HK|HU|IS|IN|ID|IR|IQ|IE|IM|IL|IT|JM|JP|JE|JO|KZ|KE|KI|KP|KR|KW|KG|LA|LV|LB|LS|LR|LY|LI|LT|LU|MO|MK|MG|MW|MY|MV|ML|MT|MH|MQ|MR|MU|YT|MX|FM|MD|MC|MN|ME|MS|MA|MZ|MM|NA|NR|NP|NL|NC|NZ|NI|NE|NG|NU|NF|MP|NO|OM|PK|PW|PS|PA|PG|PY|PE|PH|PN|PL|PT|PR|QA|RE|RO|RU|RW|BL|SH|KN|LC|MF|PM|VC|WS|SM|ST|SA|SN|RS|SC|SL|SG|SX|SK|SI|SB|SO|ZA|GS|SS|ES|LK|SD|SR|SJ|SZ|SE|CH|SY|TW|TJ|TZ|TH|TL|TG|TK|TO|TT|TN|TR|TM|TC|TV|UG|UA|AE|GB|US|UM|UY|UZ|VU|VE|VN|VG|VI|WF|EH|YE|ZM|ZW)$"
    },
    "LegalEntityType": {
      "title": "Legal Entity Type",
      "type": "string",
      "enum": [
        "individual",
        "sole_proprietorship",
        "ngo_general",
        "ngo_foundation",
        "ngo_non_profit",
        "spv",
        "spe",
        "pef",
        "pic",
        "trust",
        "foundation",
        "mdb",
        "partnership",
        "gov_intl_org",
        "gov_embassies",
        "gov_other",
        "corporate_extra_small",
        "corporate_small",
        "corporate_medium",
        "corporate_large",
        "corporate_extra_large",
        "corporate_other",
        "fi_bank",
        "fi_psp",
        "fi_crypto",
        "fi_central_bank",
        "fi_insurance",
        "fi_broker_dealer",
        "fi_msb",
        "fi_credit_union",
        "fi_investment",
        "fi_islamic",
        "fi_other",
        "funds",
        "legal_type_other"
      ]
    },
    "SystemRiskRating": {
      "title": "SystemRiskRating",
      "type": "string",
      "enum": ["low", "medium", "high"]
    },
    "SanctionScreeningResult": {
      "title": "SanctionScreeningResult",
      "type": "string",
      "enum": ["sanctioned", "not_sanctioned"]
    },
    "NumberOrString": {
      "title": "NumberOrString",
      "oneOf": [{
        "$ref": "#/definitions/nonEmptyString"
      }, {
        "type": "number"
      }]
    },
    "Date": {
      "title": "Date",
      "type": "string",
      "format": "date"
    },
    "MaybeDate": {
      "title": "MaybeDate",
      "oneOf": [{
        "type": "string",
        "format": "date"
      }, {
        "const": ""
      }]
    },
    "Address": {
      "type": "string",
      "minLength": 1,
      "faker": "address.streetAddress"
    },
    "nonEmptyString": {
      "type": "string",
      "minLength": 1
    }
  }
}

version 1.1
@totalColumns 14
@separator ','
// @efi_version 2.0
// Unique and unambiguous identification for the account between the account owner and the account servicer.
account_number: notEmpty
account_holder_id: notEmpty
full_name: notEmpty
//            For Non individuals, use it as date of incorporation
//            ISO 8601
date_of_birth: xDate
//            For Non individuals, use it as country of incorporation
place_of_birth_country: regex("^(AF|AX|AL|DZ|AS|AD|AO|AI|AQ|AG|AR|AM|AW|AU|AT|AZ|BS|BH|BD|BB|BY|BE|BZ|BJ|BM|BT|BO|BQ|BA|BW|BV|BR|IO|BN|BG|BF|BI|KH|CM|CA|CV|KY|CF|TD|CL|CN|CX|CC|CO|KM|CG|CD|CK|CR|CI|HR|CU|CW|CY|CZ|DK|DJ|DM|DO|EC|EG|SV|GQ|ER|EE|ET|FK|FO|FJ|FI|FR|GF|PF|TF|GA|GM|GE|DE|GH|GI|GR|GL|GD|GP|GU|GT|GG|GN|GW|GY|HT|HM|VA|HN|HK|HU|IS|IN|ID|IR|IQ|IE|IM|IL|IT|JM|JP|JE|JO|KZ|KE|KI|KP|KR|KW|KG|LA|LV|LB|LS|LR|LY|LI|LT|LU|MO|MK|MG|MW|MY|MV|ML|MT|MH|MQ|MR|MU|YT|MX|FM|MD|MC|MN|ME|MS|MA|MZ|MM|NA|NR|NP|NL|NC|NZ|NI|NE|NG|NU|NF|MP|NO|OM|PK|PW|PS|PA|PG|PY|PE|PH|PN|PL|PT|PR|QA|RE|RO|RU|RW|BL|SH|KN|LC|MF|PM|VC|WS|SM|ST|SA|SN|RS|SC|SL|SG|SX|SK|SI|SB|SO|ZA|GS|SS|ES|LK|SD|SR|SJ|SZ|SE|CH|SY|TW|TJ|TZ|TH|TL|TG|TK|TO|TT|TN|TR|TM|TC|TV|UG|UA|AE|GB|US|UM|UY|UZ|VU|VE|VN|VG|VI|WF|EH|YE|ZM|ZW)$")
country_citizenship: regex("^(AF|AX|AL|DZ|AS|AD|AO|AI|AQ|AG|AR|AM|AW|AU|AT|AZ|BS|BH|BD|BB|BY|BE|BZ|BJ|BM|BT|BO|BQ|BA|BW|BV|BR|IO|BN|BG|BF|BI|KH|CM|CA|CV|KY|CF|TD|CL|CN|CX|CC|CO|KM|CG|CD|CK|CR|CI|HR|CU|CW|CY|CZ|DK|DJ|DM|DO|EC|EG|SV|GQ|ER|EE|ET|FK|FO|FJ|FI|FR|GF|PF|TF|GA|GM|GE|DE|GH|GI|GR|GL|GD|GP|GU|GT|GG|GN|GW|GY|HT|HM|VA|HN|HK|HU|IS|IN|ID|IR|IQ|IE|IM|IL|IT|JM|JP|JE|JO|KZ|KE|KI|KP|KR|KW|KG|LA|LV|LB|LS|LR|LY|LI|LT|LU|MO|MK|MG|MW|MY|MV|ML|MT|MH|MQ|MR|MU|YT|MX|FM|MD|MC|MN|ME|MS|MA|MZ|MM|NA|NR|NP|NL|NC|NZ|NI|NE|NG|NU|NF|MP|NO|OM|PK|PW|PS|PA|PG|PY|PE|PH|PN|PL|PT|PR|QA|RE|RO|RU|RW|BL|SH|KN|LC|MF|PM|VC|WS|SM|ST|SA|SN|RS|SC|SL|SG|SX|SK|SI|SB|SO|ZA|GS|SS|ES|LK|SD|SR|SJ|SZ|SE|CH|SY|TW|TJ|TZ|TH|TL|TG|TK|TO|TT|TN|TR|TM|TC|TV|UG|UA|AE|GB|US|UM|UY|UZ|VU|VE|VN|VG|VI|WF|EH|YE|ZM|ZW)$")
address: notEmpty
//            ISO 3166-1 alpha-2
address_country: regex("^(AF|AX|AL|DZ|AS|AD|AO|AI|AQ|AG|AR|AM|AW|AU|AT|AZ|BS|BH|BD|BB|BY|BE|BZ|BJ|BM|BT|BO|BQ|BA|BW|BV|BR|IO|BN|BG|BF|BI|KH|CM|CA|CV|KY|CF|TD|CL|CN|CX|CC|CO|KM|CG|CD|CK|CR|CI|HR|CU|CW|CY|CZ|DK|DJ|DM|DO|EC|EG|SV|GQ|ER|EE|ET|FK|FO|FJ|FI|FR|GF|PF|TF|GA|GM|GE|DE|GH|GI|GR|GL|GD|GP|GU|GT|GG|GN|GW|GY|HT|HM|VA|HN|HK|HU|IS|IN|ID|IR|IQ|IE|IM|IL|IT|JM|JP|JE|JO|KZ|KE|KI|KP|KR|KW|KG|LA|LV|LB|LS|LR|LY|LI|LT|LU|MO|MK|MG|MW|MY|MV|ML|MT|MH|MQ|MR|MU|YT|MX|FM|MD|MC|MN|ME|MS|MA|MZ|MM|NA|NR|NP|NL|NC|NZ|NI|NE|NG|NU|NF|MP|NO|OM|PK|PW|PS|PA|PG|PY|PE|PH|PN|PL|PT|PR|QA|RE|RO|RU|RW|BL|SH|KN|LC|MF|PM|VC|WS|SM|ST|SA|SN|RS|SC|SL|SG|SX|SK|SI|SB|SO|ZA|GS|SS|ES|LK|SD|SR|SJ|SZ|SE|CH|SY|TW|TJ|TZ|TH|TL|TG|TK|TO|TT|TN|TR|TM|TC|TV|UG|UA|AE|GB|US|UM|UY|UZ|VU|VE|VN|VG|VI|WF|EH|YE|ZM|ZW)$")
legal_entity_type: any("individual", "sole_proprietorship", "ngo_general", "ngo_foundation", "ngo_non_profit", "spv", "spe", "pef", "pic", "trust", "foundation", "mdb", "partnership", "gov_intl_org", "gov_embassies", "gov_other", "corporate_extra_small", "corporate_small", "corporate_medium", "corporate_large", "corporate_extra_large", "corporate_other", "fi_bank", "fi_psp", "fi_crypto", "fi_central_bank", "fi_insurance", "fi_broker_dealer", "fi_msb", "fi_credit_union", "fi_investment", "fi_islamic", "fi_other", "funds", "legaltype_other")
system_risk_rating: any("low", "medium", "high") or empty
is_pep: any("true","false")
//            information if account holder has an association with a pep
edd_triggered: any("true","false")
is_sanctioned: any("true","false")
sanction_screening_date: xDate

File Name

The file regarding account holder data should have the prefix account_holder and the date for which it represents.

account_holder_YYYYMM.csv

For example, a file with all the data from January 2019 should be:

account_holder_201901.csv

Data Types

See more information about the data types:

• Legal entity
• Legal form
• ISIC Code
• Source of wealth
• Source of funds

Frequency

Initial submission should include records for the past year. After initial submission, submitted monthly only accounts that were not closed during the entire period, if the account was open for at least one legal second it should be included.

Sample Package

Download sample package here

Attribute Details

Transactions

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "array",
  "items": {
    "$ref": "#/definitions/TransactionElement"
  },
  "efiVersion": "2.0",
  "definitions": {
    "TransactionElement": {
      "type": "object",
      "title": "TransactionElement",
      "additionalProperties": false,
      "properties": {
        "transaction_date":                     { "$ref": "#/definitions/MaybeDate" },
        "transaction_id":                       { "$ref": "#/definitions/NumberOrString" },
        "transaction_message":                  { "$ref": "#/definitions/nonEmptyString" },
        "transaction_currency":                 { "$ref": "#/definitions/Currency" },
        "transaction_amount":                   { "$ref": "#/definitions/NumberOrString" },
        "transaction_type":                     { "$ref": "#/definitions/TransactionType" },
        "transaction_status":                   { "$ref": "#/definitions/TransactionStatus" },
        "instrument_type":                      { "$ref": "#/definitions/InstrumentType" },
        "originator_full_name":                 { "$ref": "#/definitions/nonEmptyString" },
        "originator_address":                   { "$ref": "#/definitions/nonEmptyString" },
        "originator_country":                   { "$ref": "#/definitions/Country" },
        "originator_account_number":            { "$ref": "#/definitions/nonEmptyString" },
        "originator_fi_id":                        { "$ref": "#/definitions/nonEmptyString" },
        "originator_fi_name":                   { "$ref": "#/definitions/nonEmptyString" },
        "originator_fi_country":                { "$ref": "#/definitions/nonEmptyString" },
        "incoming_intermediary_fi_ids":          { "$ref": "#/definitions/IDList" },
        "outgoing_intermediary_fi_ids":          { "$ref": "#/definitions/IDList" },
        "beneficiary_full_name":                { "$ref": "#/definitions/nonEmptyString" },
        "beneficiary_address":                  { "$ref": "#/definitions/nonEmptyString" },
        "beneficiary_country":                  { "$ref": "#/definitions/Country" },
        "beneficiary_account_number":           { "$ref": "#/definitions/NumberOrString" },
        "beneficiary_fi_id":                       { "$ref": "#/definitions/nonEmptyString" },
        "beneficiary_fi_name":                  { "$ref": "#/definitions/NumberOrString" },
        "beneficiary_fi_country":               { "$ref": "#/definitions/NumberOrString" }
      },
      "required": [
        "transaction_date",
        "transaction_id",
        "transaction_message",
        "transaction_currency",
        "transaction_amount",
        "transaction_type",
        "transaction_status",
        "instrument_type",
        "originator_full_name",
        "originator_address",
        "originator_country",
        "originator_account_number",
        "originator_fi_id",
        "originator_fi_name",
        "originator_fi_country",
        "beneficiary_full_name",
        "beneficiary_address",
        "beneficiary_country",
        "beneficiary_account_number",
        "beneficiary_fi_id",
        "beneficiary_fi_name",
        "beneficiary_fi_country"
       ]
      },
      "Country": {
        "title": "Country",
        "description": "ISO 3166-1 alpha-2 country code",
        "type": "string",
        "pattern": "^(AF|AX|AL|DZ|AS|AD|AO|AI|AQ|AG|AR|AM|AW|AU|AT|AZ|BS|BH|BD|BB|BY|BE|BZ|BJ|BM|BT|BO|BQ|BA|BW|BV|BR|IO|BN|BG|BF|BI|KH|CM|CA|CV|KY|CF|TD|CL|CN|CX|CC|CO|KM|CG|CD|CK|CR|CI|HR|CU|CW|CY|CZ|DK|DJ|DM|DO|EC|EG|SV|GQ|ER|EE|ET|FK|FO|FJ|FI|FR|GF|PF|TF|GA|GM|GE|DE|GH|GI|GR|GL|GD|GP|GU|GT|GG|GN|GW|GY|HT|HM|VA|HN|HK|HU|IS|IN|ID|IR|IQ|IE|IM|IL|IT|JM|JP|JE|JO|KZ|KE|KI|KP|KR|KW|KG|LA|LV|LB|LS|LR|LY|LI|LT|LU|MO|MK|MG|MW|MY|MV|ML|MT|MH|MQ|MR|MU|YT|MX|FM|MD|MC|MN|ME|MS|MA|MZ|MM|NA|NR|NP|NL|NC|NZ|NI|NE|NG|NU|NF|MP|NO|OM|PK|PW|PS|PA|PG|PY|PE|PH|PN|PL|PT|PR|QA|RE|RO|RU|RW|BL|SH|KN|LC|MF|PM|VC|WS|SM|ST|SA|SN|RS|SC|SL|SG|SX|SK|SI|SB|SO|ZA|GS|SS|ES|LK|SD|SR|SJ|SZ|SE|CH|SY|TW|TJ|TZ|TH|TL|TG|TK|TO|TT|TN|TR|TM|TC|TV|UG|UA|AE|GB|US|UM|UY|UZ|VU|VE|VN|VG|VI|WF|EH|YE|ZM|ZW)$"
      },
      "Currency": {
        "type": "string",
        "pattern": "^(AED|AFN|ALL|AMD|ANG|AOA|ARS|AUD|AWG|AZN|BAM|BBD|BDT|BGN|BHD|BIF|BMD|BND|BOB|BOV|BRL|BSD|BTN|BWP|BYR|BZD|CAD|CDF|CHE|CHF|CHW|CLF|CLP|CNY|COP|COU|CRC|CUC|CUP|CVE|CZK|DJF|DKK|DOP|DZD|EGP|ERN|ETB|EUR|FJD|FKP|GBP|GEL|GHS|GIP|GMD|GNF|GTQ|GYD|HKD|HNL|HRK|HTG|HUF|IDR|ILS|INR|IQD|IRR|ISK|JMD|JOD|JPY|KES|KGS|KHR|KMF|KPW|KRW|KWD|KYD|KZT|LAK|LBP|LKR|LRD|LSL|LTL|LVL|LYD|MAD|MDL|MGA|MKD|MMK|MNT|MOP|MRO|MUR|MVR|MWK|MXN|MXV|MYR|MZN|NAD|NGN|NIO|NOK|NPR|NZD|OMR|PAB|PEN|PGK|PHP|PKR|PLN|PYG|QAR|RON|RSD|RUB|RWF|SAR|SBD|SCR|SDG|SEK|SGD|SHP|SLL|SOS|SRD|SSP|STD|SVC|SYP|SZL|THB|TJS|TMT|TND|TOP|TRY|TTD|TWD|TZS|UAH|UGX|USD|USN|USS|UYI|UYU|UZS|VEF|VND|VUV|WST|XAF|XAG|XAU|XBA|XBB|XBC|XBD|XCD|XDR|XFU|XOF|XPD|XPF|XPT|XSU|XTS|XUA|XXX|YER|ZAR|ZMW|ZWL)$",
        "title": "Currency"
      },
      "InstrumentType": {
        "title": "InstrumentType",
        "type": "string",
        "enum": ["cash","check","ach/lcy_transfers","wire","securities","e-money/mobile_money","travellers_cheques","prepaid_cards","certified_cheques","vouchers","cashier_cheques/money_order","precious_metal","crypto/virtual_assets","interest/dividend","other"]
      },
      "TransactionType": {
        "title": "TransactionType",
        "type": "string",
        "description": "Populate as follows: SWIFT messages: MTXXX where XXX is sourced from 'message type' field as per https://www2.swift.com/knowledgecentre/products/Standards%20MT\nISO format messages: According to xsd for the 'message id' e.g. pain.008.001.09 https://www.iso20022.org/iso-20022-message-definitions\nFedwire/ACH/CHIPs messages: 'Business function code' as per Fedwire (3600) proprietary message format specification\n For other transaction types, please contact us before submission"
      },
      "TransactionStatus": {
        "title": "TransactionStatus",
        "type": "string",
        "enum": ["accepted", "rejected"]
      },
      "nonEmptyString": {
        "type": "string",
        "minLength": 1
      },
      "NumberOrString": {
        "title": "NumberOrString",
        "oneOf": [{
          "$ref": "#/definitions/nonEmptyString"
        }, {
          "type": "number"
        }]
      },
      "date": {
        "title": "date",
        "type": "string",
        "format": "date"
      },
      "date-time": {
        "title": "date-time",
        "type": "string",
        "format": "date-time"
      },
      "MaybeDate": {
        "title": "MaybeDate",
        "anyOf": [{
          "$ref": "#/definitions/date"
        }, {
          "$ref": "#/definitions/date-time"
        }, {
          "const": ""
        }]
      },
      "MaybeString": {
        "title": "MaybeString",
        "anyOf": [{
          "type": "string"
        }, {
          "const": ""
        }]
      },
      "IDList": {
        "oneOf": [{
          "type": "string",
          "pattern": "([a-zA-Z]{4}[a-zA-Z]{2}[a-zA-Z0-9]{2}([a-zA-Z0-9]{3})?;?)+"
        }, {
          "const": ""
        }]
      }
    }
}

version 1.1
@totalColumns 24
@separator ','
// @efi_version 2.0
transaction_date: xDateTimeTz
transaction_id: notEmpty
transaction_message: notEmpty
// ISO 4217
transaction_currency: regex("^(AED|AFN|ALL|AMD|ANG|AOA|ARS|AUD|AWG|AZN|BAM|BBD|BDT|BGN|BHD|BIF|BMD|BND|BOB|BOV|BRL|BSD|BTN|BWP|BYR|BZD|CAD|CDF|CHE|CHF|CHW|CLF|CLP|CNY|COP|COU|CRC|CUC|CUP|CVE|CZK|DJF|DKK|DOP|DZD|EGP|ERN|ETB|EUR|FJD|FKP|GBP|GEL|GHS|GIP|GMD|GNF|GTQ|GYD|HKD|HNL|HRK|HTG|HUF|IDR|ILS|INR|IQD|IRR|ISK|JMD|JOD|JPY|KES|KGS|KHR|KMF|KPW|KRW|KWD|KYD|KZT|LAK|LBP|LKR|LRD|LSL|LTL|LVL|LYD|MAD|MDL|MGA|MKD|MMK|MNT|MOP|MRO|MUR|MVR|MWK|MXN|MXV|MYR|MZN|NAD|NGN|NIO|NOK|NPR|NZD|OMR|PAB|PEN|PGK|PHP|PKR|PLN|PYG|QAR|RON|RSD|RUB|RWF|SAR|SBD|SCR|SDG|SEK|SGD|SHP|SLL|SOS|SRD|SSP|STD|SVC|SYP|SZL|THB|TJS|TMT|TND|TOP|TRY|TTD|TWD|TZS|UAH|UGX|USD|USN|USS|UYI|UYU|UZS|VEF|VND|VUV|WST|XAF|XAG|XAU|XBA|XBB|XBC|XBD|XCD|XDR|XFU|XOF|XPD|XPF|XPT|XSU|XTS|XUA|XXX|YER|ZAR|ZMW|ZWL)$")
// Amount rounded to the smallest currency unit
transaction_amount: notEmpty
// Populate as follows:
// SWIFT messages: MTXXX where XXX is sourced from "message type" field as per https://www2.swift.com/knowledgecentre/products/Standards%20MT
// ISO format messages: According to xsd for the "message id" e.g. pain.008.001.09 https://www.iso20022.org/iso-20022-message-definitions
// Fedwire/ACH/CHIPs messages: "Business function code" as per Fedwire (3600) proprietary message format specification
// For other transaction types, please contact us before submission
transaction_type: notEmpty
transaction_status: any("accepted", "rejected")
instrument_type: any("cash","check","ach/lcy_transfers","wire","securities","e-money/mobile_money","travellers_cheques","prepaid_cards","certified_cheques","vouchers","cashier_cheques/money_order","precious_metal","crypto/virtual_assets","interest/dividend","other")
originator_full_name: notEmpty
originator_address: notEmpty
// ISO 3166-1 alpha-2
originator_country: regex("^(AF|AX|AL|DZ|AS|AD|AO|AI|AQ|AG|AR|AM|AW|AU|AT|AZ|BS|BH|BD|BB|BY|BE|BZ|BJ|BM|BT|BO|BQ|BA|BW|BV|BR|IO|BN|BG|BF|BI|KH|CM|CA|CV|KY|CF|TD|CL|CN|CX|CC|CO|KM|CG|CD|CK|CR|CI|HR|CU|CW|CY|CZ|DK|DJ|DM|DO|EC|EG|SV|GQ|ER|EE|ET|FK|FO|FJ|FI|FR|GF|PF|TF|GA|GM|GE|DE|GH|GI|GR|GL|GD|GP|GU|GT|GG|GN|GW|GY|HT|HM|VA|HN|HK|HU|IS|IN|ID|IR|IQ|IE|IM|IL|IT|JM|JP|JE|JO|KZ|KE|KI|KP|KR|KW|KG|LA|LV|LB|LS|LR|LY|LI|LT|LU|MO|MK|MG|MW|MY|MV|ML|MT|MH|MQ|MR|MU|YT|MX|FM|MD|MC|MN|ME|MS|MA|MZ|MM|NA|NR|NP|NL|NC|NZ|NI|NE|NG|NU|NF|MP|NO|OM|PK|PW|PS|PA|PG|PY|PE|PH|PN|PL|PT|PR|QA|RE|RO|RU|RW|BL|SH|KN|LC|MF|PM|VC|WS|SM|ST|SA|SN|RS|SC|SL|SG|SX|SK|SI|SB|SO|ZA|GS|SS|ES|LK|SD|SR|SJ|SZ|SE|CH|SY|TW|TJ|TZ|TH|TL|TG|TK|TO|TT|TN|TR|TM|TC|TV|UG|UA|AE|GB|US|UM|UY|UZ|VU|VE|VN|VG|VI|WF|EH|YE|ZM|ZW)$")
// Internal customer account number
originator_account_number: notEmpty
// Accepted values are BIC (ISO 9362), ABA routing number or CHIPS Uid
originator_fi_id: notEmpty
originator_fi_name: notEmpty
originator_fi_country: notEmpty
// incoming_intermediary_fi_ids can be one or a list of BIC, ABA, CHIPS codes separated by `;` they should contain all intermediaries before the processor institution
incoming_intermediary_fi_ids: notEmpty or empty
// outgoing_intermediary_fi_ids can be one or a list of BIC, ABA, CHIPS codes separated by `;` they should contain all intermediaries after the processor institution
outgoing_intermediary_fi_ids: notEmpty or empty
beneficiary_full_name: notEmpty
beneficiary_address: notEmpty
// ISO 3166-1 alpha-2
beneficiary_country: regex("^(AF|AX|AL|DZ|AS|AD|AO|AI|AQ|AG|AR|AM|AW|AU|AT|AZ|BS|BH|BD|BB|BY|BE|BZ|BJ|BM|BT|BO|BQ|BA|BW|BV|BR|IO|BN|BG|BF|BI|KH|CM|CA|CV|KY|CF|TD|CL|CN|CX|CC|CO|KM|CG|CD|CK|CR|CI|HR|CU|CW|CY|CZ|DK|DJ|DM|DO|EC|EG|SV|GQ|ER|EE|ET|FK|FO|FJ|FI|FR|GF|PF|TF|GA|GM|GE|DE|GH|GI|GR|GL|GD|GP|GU|GT|GG|GN|GW|GY|HT|HM|VA|HN|HK|HU|IS|IN|ID|IR|IQ|IE|IM|IL|IT|JM|JP|JE|JO|KZ|KE|KI|KP|KR|KW|KG|LA|LV|LB|LS|LR|LY|LI|LT|LU|MO|MK|MG|MW|MY|MV|ML|MT|MH|MQ|MR|MU|YT|MX|FM|MD|MC|MN|ME|MS|MA|MZ|MM|NA|NR|NP|NL|NC|NZ|NI|NE|NG|NU|NF|MP|NO|OM|PK|PW|PS|PA|PG|PY|PE|PH|PN|PL|PT|PR|QA|RE|RO|RU|RW|BL|SH|KN|LC|MF|PM|VC|WS|SM|ST|SA|SN|RS|SC|SL|SG|SX|SK|SI|SB|SO|ZA|GS|SS|ES|LK|SD|SR|SJ|SZ|SE|CH|SY|TW|TJ|TZ|TH|TL|TG|TK|TO|TT|TN|TR|TM|TC|TV|UG|UA|AE|GB|US|UM|UY|UZ|VU|VE|VN|VG|VI|WF|EH|YE|ZM|ZW)$")
beneficiary_account_number: notEmpty
// Accepted values are BIC (ISO 9362), ABA routing number or CHIPS Uid
beneficiary_fi_id: notEmpty
beneficiary_fi_name: notEmpty
beneficiary_fi_country: notEmpty

File Name

The file regarding transaction data should have the prefix transactions and the date for which it represents.

transactions_YYYYMM.csv

For example, a file with all the data from January 2019 should be:

transactions_201901.csv

Frequency

Initial submission should include transactions for the past year. After initial submission, submitted monthly only with the previous month transactions. If no new transactions occurred, submit the file only with the header.

Sample Package

Download sample package here

Attribute Details

Sanctions Screening

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "array",
  "items": {
    "$ref": "#/definitions/SanctionsScreeningElement"
  },
  "efiversion": "2.0",
  "definitions": {
    "SanctionsScreeningElement": {
      "title": "SanctionsScreeningElement",
      "type": "object",
      "properties": {
        "transaction_id":             { "$ref": "#/definitions/MaybeId" },
        "fi_id":                      { "$ref": "#/definitions/MaybeId" },
        "full_name":                  { "$ref": "#/definitions/nonEmptyString" },
        "account_number":             { "$ref": "#/definitions/MaybeId" },
        "is_sanctioned":              { "type": "boolean" },
        "sanction_screening_date":    { "$ref": "#/definitions/Date" },
        "is_licensed":              { "type": "boolean" }
      },
      "required": [
              "transaction_id",
              "fi_id",
              "full_name",
              "account_number",
              "is_sanctioned",
              "sanction_screening_date",
              "is_licensed"
            ]
    },
    "MaybeId": {
      "title": "NumberOrString",
      "oneOf": [{
        "$ref": "#/definitions/nonEmptyString"
      }, {
        "type": "number"
      }, {
        "const": ""
      }]
    },
    "nonEmptyString": {
          "type": "string",
          "minLength": 1
    },
    "Date": {
      "title": "Date",
      "type": "string",
      "format": "date"
    },
    "DateTime": {
      "title": "date",
      "type": "string",
      "format": "date-time"
    }
  }
}

version 1.1
@totalColumns 5
@separator ','
// @efi_version 2.0
// Transaction id can be included for merging with a specific transaction
transaction_id: notEmpty or empty
// Accepted values are BIC (ISO 9362), ABA routing number or CHIPS Uid
fi_id: notEmpty or empty
full_name: notEmpty
// Referenced in account_holder file
account_number: notEmpty or empty
is_sanctioned:  any("true","false")
sanction_screening_date: xDate
is_licensed:  any("true","false")

This file is used to minimize the possibility of getting false positive sanction hits by Elucidate by taking in the information from the firm.

File Name

The file regarding sanctions screening data should have the prefix sanctions_screening and the date for which it represents.

sanctions_screening_YYYYMM.csv

For example, a file with all the data from January 2019 should be:

sanctions_screening_201901.csv

Frequency

After initial submission, submitted monthly only with the previous month's screening report. If no false positive hits occur, submit the file only with the header.

Sample Package

Download sample package here

Attribute Details

Screening Service

The Elucidate Transaction Screening, Monitoring and Validation Service operates against its own set of datasets, separate from the institution data described above. This section is a summary subset of the full reference, intended to give an at-a-glance view of which datasets the screening service consumes and produces.

Screening Requests

Transaction-message screening requests are the primary input to the service. Each request embeds a base64-encoded message that represents either a SWIFT MT message (mt103, mt199, mt202, mt299, mt499, mt599, mt700, mt701, mt705, mt707, mt710, mt711, mt720, mt742, mt747, mt750, mt752, mt754, mt756, mt760, mt767, mt768, mt769, mt799, generic mt) or an ISO 20022 message (mx, e.g. pacs.008.001.08).

Requests are submitted in batches and processed asynchronously against the Elucidate risk model. Consumers either poll the status of each request by its identifier or receive completion notifications via webhook. The outcome of a completed request is a decision (ALLOW / BLOCK) accompanied by a reason, a per-module result detail, and — where the decision is taken by a reviewer — the recorded user decision.

Customer Data

Identity and AML information for individual customers, stored per institution and uniquely keyed by customerNumber. When watchlist screening is enabled for the institution, records are automatically screened against active sanction and watchlist sources on creation and update; results are written back onto the record as sanctioned (boolean) and sanction_information (detailed hit data).

A customer record can carry: customer attributes (gender, birthPlace, nationality and secondary nationalities, idType, clientType — Corporate, Person, or Financial Institution — and dateBirth); transaction-context fields (transactionDate, userName, userId); and an amlInfo array of {tag, name} entries that drive the watchlist screening (for example CI112001 for customer name and CI114001 for country).

Supplementary Data

Additional structured information attached to a screening request after creation. Particularly relevant for trade-finance flows (e.g. MT700 Letter of Credit) where trade details, invoices, transport documents, and certificates arrive separately from the original message and must be linked back to the screening request to support future monitoring scenarios such as over- and under-invoicing checks.

The entity name and structure follow the ISO 20022 SplmtryData element. Each supplementary data record has its own independent assessment lifecycle (PENDING → PROCESSING → COMPLETE or ERROR), separate from the parent screening request, and multiple records may be attached to a single request.

Supported delivery channels are SWIFT FIN (tag-based MT, parsed to JSON), InterAct (real-time ISO 20022 XML, parsed to JSON), FileAct (bulk CSV / XML), and direct JSON submission. Common dataType values map to the ISO 20022 trade data sets CommercialDataSet, TransportDataSet, InsuranceDataSet, and OtherCertificateDataSet (tsmt.014), with HS classification codes for goods, UN/LOCODE for ports, and ICC Incoterms 2020 for trade terms. Base64-encoded PDF attachments are accepted for scanned or non-structured documents.

AI Readiness

The datasets listed in this section are requested on a voluntary basis to support an institution's AI readiness. They sit outside the mandatory data protocol described above; an institution may submit any subset, based on what its source systems can produce and what its legal and operational constraints permit. Nothing here is required for the EFI assessment to proceed.

AI readiness is worth starting on now because the bottleneck for AI in regulated financial-crime workflows is not the model itself — it is the availability, lineage, and assurance backing of the data the model would consume.

The datasets in this section are the ones that take longest to organise retrospectively, and they are the same datasets supervisors expect to see evidenced when an AI-driven decision is challenged.

Beginning the work before a specific use case is approved means the readiness layer is built against data the institution already produces, at a cadence the institution controls, with no model yet in production — so the cost of starting is low and the option value is high.

The same work compounds into the existing control environment well before any AI is deployed: cleaner inputs to monitoring and screening, more defensible exit decisions, faster audit responses, and a shorter distance between a supervisory question and a documented answer.

Institutions that defer this work tend to find that the data and evidence layers become the critical path on every later AI programme; institutions that start now treat them as ambient infrastructure rather than as a project. The direction of supervisory expectation is broadly consistent across jurisdictions — see Regulatory Context below.

Schema is intentionally not prescribed. We do not require these datasets in a fixed shape — field names, encodings, normalisation level, code-list values, and record granularity will vary across core systems, screening platforms, case-management tools, and audit and assurance systems.

Elucidate works with the institution during discovery to derive a working schema from whatever the source systems actually hold, and to map source fields to a canonical form inside the bank boundary.

The only invariants we ask for are a stable record identifier and a timestamp on each record; everything else is negotiated against what the source can produce.

All voluntary datasets are pseudonymised at the bank boundary using the same mechanisms described under Pseudonymisation. Cadence, format, and transport are agreed during discovery and aligned with the mandatory protocol where it is operationally convenient to do so.

Regulatory Context

AI readiness is being shaped by a converging set of supervisory frameworks. They differ on style — the UK leans principles-based, the EU leans prescriptive, the US is risk-tiered around the model lifecycle — but they agree on the substance: an institution deploying AI in regulated workflows must be able to evidence the data inputs, the decision path, the model version, and the human accountability behind every outcome.

The datasets in this section are what that evidence is built on.

Jurisdiction	Authority	Primary reference
United Kingdom	Financial Conduct Authority (FCA)	AI approach — principles-based, outcomes-focused. No AI-specific rules planned; existing accountability under the Consumer Duty and the Senior Managers and Certification Regime (SM&CR) does the work. Last updated 13 February 2026.
European Union	European Commission / EBA / ECB	EU AI Act — full rules applicable from 2 August 2026, with a risk-tier classification (prohibited / high-risk / limited-risk / minimal) that determines documentation obligations. See the EBA factsheet on AI Act implications for the banking and payments sector and ECB Banking Supervision treating AI governance under Supervisory Priority 2 (operational resilience and ICT capabilities) for 2026–28.
United States	Federal Reserve / OCC / FDIC	SR 11-7 model risk management, refined for 2026 by the interagency update SR 26-02 (more explicit risk-based scoping).
Singapore	Monetary Authority of Singapore (MAS)	FEAT principles; Guidelines for AI Risk Management; the industry-collaborative AI Risk Management Toolkit (Project MindForge).
Hong Kong	Hong Kong Monetary Authority (HKMA)	HKMA principles for AI use in banking; Fintech Promotion Blueprint; GenA.I. Sandbox++ for supervised experimentation.
Canada	Office of the Superintendent of Financial Institutions (OSFI)	Guideline B-13 (technology and cyber risk); Guideline E-23 (model risk management).
Australia	AUSTRAC	AI transparency statement; under the 2026 AML/CTF reform, AI use must be described inside the firm's AML/CTF programme documentation.

The UK's FCA position is the most useful single anchor for this section, because it is the framework that least prescribes the technical shape of AI controls and most relies on the institution being able to evidence what it did and why.

A firm that can answer the FCA's outcome-based questions can, in practice, also answer the more prescriptive ones from the EU AI Act, SR 11-7, MAS, HKMA, OSFI and AUSTRAC — provided the underlying data and assurance layers are in place. That is the layer this section is concerned with.

Transactional Data

This bucket captures the residual transactional signal that conventional monitoring suppressed, escalated, or stopped — the activity that did not clear the front line cleanly, and that is therefore most informative about how the financial-crime control environment behaves in practice.

• Unmonitored transactions — transactions excluded from rules-based monitoring at source, together with the exclusion reason where available (segment carve-out, threshold suppression, product exemption, technical bypass, sanctioned-corridor filter). Population-level counts are useful even where line-level extracts are not feasible.
• Transaction monitoring escalation and investigation — alerts that progressed from generation through L1 / L2 / L3 review: the disposition at each stage, the time-in-queue, the analyst rationale, and the final outcome (closed no further action, SAR / STR filed, account action). Linkage back to the underlying transaction identifier is preferred but not required.
• Payment stops and rejections — payments held or rejected pre-settlement, with the reason code or free-text justification, the queue or hold-bucket the payment sat in, the dwell time, and the resolution path (released, returned, cancelled).
• Sanctions investigations — screening alerts that were taken into investigation beyond automated false-positive discounting, including the matched list and list entry, the analyst rationale for the final disposition, and any external reporting that was triggered as a consequence.
• Internal watchlists — bank-maintained entries (entities, counterparties, individuals, jurisdictions) under enhanced scrutiny, exit, or do-not-onboard status, with the addition reason, the originating function, and the review or expiry cadence.

Customer Data

This bucket captures lifecycle decisions that conventional onboarding and periodic-review extracts do not surface — the cases where the institution either declined to start a relationship or chose to end one, and the qualitative evidence that supports the relationships that remain.

• Customer rejections and exits — applicants declined at onboarding and relationships terminated post-onboarding, with the reason code, the deciding function (financial crime, credit, commercial, regulatory), and any external notification that was raised.
• Extended customer data — attributes beyond those captured in the Account Holder protocol: enhanced due diligence narratives, source-of-wealth corroboration, adverse media review outcomes, relationship manager assessments, and periodic-review depth indicators. Free-text narrative fields are accepted as-is and are pseudonymised at the boundary.

Control Effectiveness

This bucket captures how the institution's own assurance functions assess the financial-crime control environment — the inside view that transactional and customer data alone cannot evidence.

• Audit reports and audit results — internal audit reviews covering financial-crime controls, the rating awarded, the underlying findings, management responses, and remediation status against agreed dates.
• QA reports and QA results — first-line quality-assurance reviews of monitoring alerts, screening dispositions, and CDD case work, with the sampling design, the error rates observed, the categorisation of those errors, and the trend over time.
• Assurance results — second-line compliance assurance reviews, the scope and population covered, the rating issued, and the issues raised against the operating effectiveness of the underlying controls.

Agentic AI

Agentic AI — autonomous software agents that operate against the institution's existing systems and tools, rather than running as fixed integration pipelines — is the natural fit for the consolidation problem the datasets above create.

The datasets typically live across several systems: the transaction monitoring platform, the screening tool, one or more case-management systems, GRC and audit tooling, an analytics warehouse, and the spreadsheets and shared drives that fill the gaps.

Bringing them into a single consolidated shape has historically required a multi-quarter integration programme — API contracts and credentials per source, ETL pipelines, data-warehouse modelling, lineage tooling, and governance sign-off on each connector — and that programme often takes longer than the AI readiness work it was meant to enable.

Eli, the Elucidate autonomous compliance agent, removes most of that step. The agent operates against the systems the institution already runs, inside the institution's environment, and produces the consolidated dataset shape required by this section without the institution standing up bespoke ingestion pipelines, signing off a strategic data-platform deployment, or committing to a big-tech integration build.

It reads what is there, normalises and reconciles it inside the bank boundary, and hands the consolidated record on — schema-neutral on the source side, schema-stable on the output side, with pseudonymisation applied as per Pseudonymisation.

The practical effect is that the entry cost of AI readiness drops to the cost of granting the agent read access to the existing systems and the data within.

The work of merging, deduplicating and consolidating becomes an agent task rather than an integration project, and the institution can move on the readiness layer without first committing to a platform programme.

Common Types

BIC

Specify the Bank Identification Code. It is an 8 to 11-character code that is used to identify a specific bank.

"BIC": {
  "type": "string",
  "pattern": "([a-zA-Z]{4}[a-zA-Z]{2}[a-zA-Z0-9]{2}([a-zA-Z0-9]{3})?)?"
}

Legal Entity

Specify the legal structure by which the entity is organised. Could be an individual or group.

"LegalEntityType": {
  "title": "Legal Entity Type",
  "type": "string",
  "enum": [
    "individual",
    "sole_proprietorship",
    "ngo_general",
    "ngo_foundation",
    "ngo_non_profit",
    "spv",
    "spe",
    "pef",
    "pic",
    "trust",
    "foundation",
    "mdb",
    "partnership",
    "gov_intl_org",
    "gov_embassies",
    "gov_other",
    "corporate_extra_small",
    "corporate_small",
    "corporate_medium",
    "corporate_large",
    "corporate_extra_large",
    "corporate_other",
    "fi_bank",
    "fi_psp",
    "fi_crypto",
    "fi_central_bank",
    "fi_insurance",
    "fi_broker_dealer",
    "fi_msb",
    "fi_credit_union",
    "fi_investment",
    "fi_islamic",
    "fi_other",
    "funds",
    "legal_type_other"
  ]
}

Legal entities
├── individual
├── sole_proprietorship
├── ngo
│   ├── ngo_general
│   ├── ngo_foundation
│   └── ngo_non_profit
├── spv
├── spe
├── pef
├── pic
├── trust
├── foundation
├── mdb
├── partnership
├── gov
│   ├── gov_intl_org
│   ├── gov_embassies
│   └── gov_other
├── corporate
│   ├── corporate_extra_small
│   ├── corporate_small
│   ├── corporate_medium
│   ├── corporate_large
│   ├── corporate_extra_large
│   └── corporate_other
├── fi
│   ├── fi_bank
│   ├── fi_psp
│   ├── fi_crypto
│   ├── fi_central_bank
│   ├── fi_insurance
│   ├── fi_broker_dealer
│   ├── fi_msb
│   ├── fi_credit_union
│   ├── fi_investment
│   ├── fi_islamic
│   └── fi_other
├── funds
└── legal_type_other

System Risk Rating

Specify the risk rating that the institution assigned the entity.

"SystemRiskRating": {
  "title": "SystemRiskRating",
  "type": "string",
  "enum": ["low", "medium", "high"]
}

Country

Specify the ISO 3166-1 alpha-2 country code.

"Country": {
  "title": "Country",
  "description": "ISO 3166-1 alpha-2 country code",
  "type": "string",
  "pattern": "^(AF|AX|AL|DZ|AS|AD|AO|AI|AQ|AG|AR|AM|AW|AU|AT|AZ|BS|BH|BD|BB|BY|BE|BZ|BJ|BM|BT|BO|BQ|BA|BW|BV|BR|IO|BN|BG|BF|BI|KH|CM|CA|CV|KY|CF|TD|CL|CN|CX|CC|CO|KM|CG|CD|CK|CR|CI|HR|CU|CW|CY|CZ|DK|DJ|DM|DO|EC|EG|SV|GQ|ER|EE|ET|FK|FO|FJ|FI|FR|GF|PF|TF|GA|GM|GE|DE|GH|GI|GR|GL|GD|GP|GU|GT|GG|GN|GW|GY|HT|HM|VA|HN|HK|HU|IS|IN|ID|IR|IQ|IE|IM|IL|IT|JM|JP|JE|JO|KZ|KE|KI|KP|KR|KW|KG|LA|LV|LB|LS|LR|LY|LI|LT|LU|MO|MK|MG|MW|MY|MV|ML|MT|MH|MQ|MR|MU|YT|MX|FM|MD|MC|MN|ME|MS|MA|MZ|MM|NA|NR|NP|NL|NC|NZ|NI|NE|NG|NU|NF|MP|NO|OM|PK|PW|PS|PA|PG|PY|PE|PH|PN|PL|PT|PR|QA|RE|RO|RU|RW|BL|SH|KN|LC|MF|PM|VC|WS|SM|ST|SA|SN|RS|SC|SL|SG|SX|SK|SI|SB|SO|ZA|GS|SS|ES|LK|SD|SR|SJ|SZ|SE|CH|SY|TW|TJ|TZ|TH|TL|TG|TK|TO|TT|TN|TR|TM|TC|TV|UG|UA|AE|GB|US|UM|UY|UZ|VU|VE|VN|VG|VI|WF|EH|YE|ZM|ZW)$"
}

Currency

Specify the three-letter ISO currency code.

"Currency": {
  "type": "string",
  "pattern": "^(AED|AFN|ALL|AMD|ANG|AOA|ARS|AUD|AWG|AZN|BAM|BBD|BDT|BGN|BHD|BIF|BMD|BND|BOB|BOV|BRL|BSD|BTN|BWP|BYN|BYR|BZD|CAD|CDF|CHE|CHF|CHW|CLF|CLP|CNY|COP|COU|CRC|CUC|CUP|CVE|CZK|DJF|DKK|DOP|DZD|EGP|ERN|ETB|EUR|FJD|FKP|GBP|GEL|GHS|GIP|GMD|GNF|GTQ|GYD|HKD|HNL|HRK|HTG|HUF|IDR|ILS|INR|IQD|IRR|ISK|JMD|JOD|JPY|KES|KGS|KHR|KMF|KPW|KRW|KWD|KYD|KZT|LAK|LBP|LKR|LRD|LSL|LTL|LVL|LYD|MAD|MDL|MGA|MKD|MMK|MNT|MOP|MRO|MRU|MUR|MVR|MWK|MXN|MXV|MYR|MZN|NAD|NGN|NIO|NOK|NPR|NZD|OMR|PAB|PEN|PGK|PHP|PKR|PLN|PYG|QAR|RON|RSD|RUB|RWF|SAR|SBD|SCR|SDG|SEK|SGD|SHP|SLE|SLL|SOS|SRD|SSP|STD|STN|SVC|SYP|SZL|THB|TJS|TMT|TND|TOP|TRY|TTD|TWD|TZS|UAH|UGX|USD|USN|USS|UYI|UYU|UZS|VEF|VES|VND|VUV|WST|XAF|XAG|XAU|XBA|XBB|XBC|XBD|XCD|XDR|XFU|XOF|XPD|XPF|XPT|XSU|XTS|XUA|XXX|YER|ZAR|ZMW|ZWG|ZWL)$",
  "title": "Currency"
}

Date

Specify the date in the YYYY-MM-DD format.

"Date": {
  "title": "date",
  "type": "string",
  "format": "date",
}

Date or Empty

Specify the date in the YYYY-MM-DD format or leave empty.

"MaybeDate": {
  "title": "date",
  "oneOf": [{
    "type": "string",
    "format": "date",
    "example": "2020-02-18"
  }, {
    "const": ""
  }]
}

DateTime Timezone-aware

Specify the datetime in the YYYY-MM-DDThh:mm:ssTZD format.

"DateTime": {
  "title": "date",
  "type": "string",
  "format": "date-time",
  "example": "2020-02-18T12:43:46Z"
}

DateTime Timezone-aware or Empty

Specify the datetime in the YYYY-MM-DDThh:mm:ssTZD format or leave empty.

"MaybeDateTime": {
  "title": "MaybeDateTime",
  "oneOf": [{
    "type": "string",
    "format": "date-time",
    "example": "2020-02-18T12:43:46Z"
  }, {
    "const": ""
  }]
}

Address

Street address.

"Address": {
  "type": "string",
  "minLength": 1,
  "faker": "address.streetAddress"
}

Non empty string

Denotes that the string must be filled in.

"nonEmptyString": {
  "type": "string",
  "minLength": 1
}

Empty string

Denotes that the string can be empty.

"emptyString": {
  "const": ""
}

Warning if Empty

As there is no easy way to trigger warning instead of an error, this data type is added. One can set it to a minLength: 1 or so to check for strictness.

"WarnIfEmpty": {
  "type": "string",
  "title": "Warning if empty",
  "description": "Recommended to have"
}

Not Collected

The institution does not collect this information.

"not_collected"

Pseudonymisation

$ hash('algo', "some text") : "uniqueString"

We treat all data submitted to us as highly confidential and apply industry best practices for data security. If you wish to learn more about our process, please contact us at security@elucidate.co.

If you prefer to pseudonymise data before submission to us, we request that you:

1. Choose an pseudonymisation algorithm from those listed below, in order of preference
2. Using the chosen algorithm, generate hashes for the following sample names & date:
   • 2020-06-17
   • ahmed, abubakar
   • поддръжници на исляма в кюрдистан
   • anwar nasser abdulla al-aulaqi
   • taha yassin ramadan al-jizrawi
   • عبد العالي ابو ذر
3. Generate the pseudonymisation_checksum_YYYYMM file. This file should contain the following headers: |created_month|input_value|pseudonymisation_algorithm|output|, where
   • created_month corresponds to the month of submission in the format YYYY-MM
   • input_value are the sample names (one row each)
   • pseudonymisation_algorithm is the algorithm in use SHA-3/BLAKE2B/MD5
   • Output is the pseudonymised hash value obtained
4. Provide an pseudonymisation file each month along with your data submission

Please see our article on the Support Portal for additional information on how data can be pseudonymised and anonymised

SHA-3

SHA-3 (Secure Hash Algorithm 3) is the latest member of the Secure Hash Algorithm family of standards, released by NIST on August 5, 2015. Although part of the same series of standards, SHA-3 is internally quite different from the MD5-like structure of SHA-1 and SHA-2.

Wikipedia article

PHP

<?php

$value = 'Example $5ãÇ д赛یラ Company Co. Ltd.';
print("original: ".$value."\n");

$value =  preg_replace(
  '/[^\w$\x{0080}-\x{FFFF}]|\$+/u',
  '',
  mb_strtolower($value)
);
$value = hash('sha3-512', $value);

print("digested: ".$value."\n");

Node.js

const crypto = require('crypto');

let value = 'Example $5ãÇ д赛یラ Company Co. Ltd.'
console.log('original: '+value+'\n')

value = value.toLowerCase().replace(/[^\p{L}0-9]/gu, '')
value = crypto.createHash('sha3-512').update(value).digest('hex')
console.log('digested: '+value+'\n')

Python

import re
import hashlib

value = 'Example $5ãÇ д赛یラ Company Co. Ltd.'
print(f'original: {value}')

value = re.sub(r'[^\w]', '', value.lower())
value = hashlib.sha3_512(value.encode()).hexdigest()

print(f'digested: {value}')

Shell

#!/bin/bash

value='Example $5ãÇ д赛یラ Company Co. Ltd.'
echo "original: "$value

echo -n "digested: "
echo $value \
  | sed -E 's/([[:alpha:]]*)/\L\1/g' \
  | sed -E 's/[^[:alnum:]]//g' \
  | openssl dgst -sha512 \
  | cut -d' ' -f2

Sample

You can find a sample of the algorithm's application here

BLAKE2b

$ hash('BLAKE2b' , 'String you want to hash')

:"14c7a49806ce0ebb34ccfe00a90cbf9a0252eb8b1dafcdd80ed9678bc942be1dcd09718058babeb7e625d224f4ef65b7d4b93848c78af6ac56791443fb7ab8f6"

BLAKE and BLAKE2 are cryptographic hash functions based on Dan Bernstein's ChaCha stream cipher, but a permuted copy of the input block, XORed with some round constants, is added before each ChaCha round.

Wikipedia article

Sample

You can find a sample of the algorithm's application here

MD5

$ hash('md5' , 'String you want to hash')

: "502a25edec758b7a10c56e6fde700cae"

The MD5 message-digest algorithm is a widely used hash function producing a 128-bit hash value. Although MD5 was initially designed to be used as a cryptographic hash function, it has been found to suffer from extensive vulnerabilities. It can still be used as a checksum to verify data integrity, but only against unintentional corruption.

Wikipedia article

Sample

You can find a sample of the algorithm's application here

Normalisation

Before applying the desired algorithm, we request that you apply the following normalisations:

1. lower case
2. no consecutive whitespaces
3. no pre or post whitespace
4. utf-8 encoding

Security

There are two methods of delivery:

• Manual delivery - You can use our platform https://efi.elucidate.co to securely upload and submit files

• API delivery - We have an API available which allows you to automate the delivery of data. The documentation is available at https://docs.elucidate.co/api

If you wish to encrypt the data on your side you can use our public key from here

Errors

A validation tool will run offline on the server side. If we encounter any error in the files you have provided we will contact you for resubmission.

© Elucidate GmbH imprint