Data Integration Guide - Anti-Money Laundering

 

Preface

This document serves as general reference for data integration supporting out-of-the-box Anti-Money Laundering use cases within Datavisor’s platform. The elements discussed below, highlight Datavisor’s ability to support AML based risk assessment by leveraging flexible API data architecture and powerful industry partnerships. Each data dictionary is designed to communicate essential and required data elements pertinent to addressing use case specific prevention efficacy. For additional requirements, Datavisor’s Customer Success team is available to orchestrate tailored data integration options.

 

KYC/CDD/EDD 

For the AML use case, DataVisor primarily uses customer profile data for both KYC screening and CDD reporting. In addition, complete customer profile data also enables more powerful linkage analysis to discover suspicious networks and anomalies.

DataVisor integrates with top vendors in this space for identity verification and can easily integrate additional vendors upon requests.

Sanction screening

DataVisor is extremely flexible and efficient in integration Sanction Screening capabilities. From the integration approach perspective, DataVisor supports both external vendors through APIs and internal customized matching algorithms. From the data perspective, DataVisor supports curated vendor data that provides global sanction data including PEPs, Adverse Media, and lists such as OFAC, UN, HMT, EU, DFAT, as well as in-house custom lists. See below table for a summary.

Due diligence can be achieved by screening customers during onboarding and continuously monitoring against subsequent account profile updates and transactions. In addition, DataVisor fully supports screening against multiple in-house Sanction Lists.

 

	Flexibilities	Descriptions	Examples
Integration approach	External Vendor	DataVisor can work with any preferred vendors that support API-based approaches.	ComplyAdvantage, KYC2020
	Internal Match Logic	DataVisor supports configurations of in-house matching algorithms.	String matching algorithms such as “Edit distance” and “Levenshtein distance”.
Integration Data	External Vendor Data	PEPs, Adverse Media, OFAC, UN, HMT, EU, DFAT, etc	ComplyAdvantage
	In-house Sanction List	Customizable name list for screening

 

Customer data

Fields that are helpful for customer data include:

Fields marked Required suggest the minimum data elements needed to support a standard out-of-box integration. The exclusion of any of these data points will not break the Datavisor system but may degrade the efficacy of the solution.

Category	Data Field	Description	Required
Account Creation	Customer ID	Unique customer ID within the financial institution
	Tax ID	Unique tax identifier of the customer, such as SSN / ITIN	X
	Account creation time	The time the account is created with the financial institution	X
	Account type	Type of account being created	X
	Account ID	Unique ID of the account
	Customer tenure	Tenure of the customer
	Email	Email address of the customer	X
	Phone	Phone number of the customer, or phone prefix	X
	IP Address	IP address of the customer at account creation
	Full Name	The full name of the customer	X
	Address	The address of the customer	X
	Country of residence	The country of residence of the customer	X
	City	The city of the customer	X
	State	The state of the customer	X
	Zip Code	The zip code of the customer	X
	Country of citizenship	The country of citizenship of the customer	X
	Date of Birth	Date of birth of the customer	X
	Annual Income	Annual income of the customer
	Monthly Rent	Monthly rent paid by the customer
	Employment Tenure	How long the customer has been working for their current employer
	Employment Status	Customer’s current employment status
	Employer	Employer name of the customer
	Account open date	Account open date
Profile Update	Address
	Country
	City
	State
	Zip Code
	Phone
	Email
	Profile update date	Profile update date	X

 

Real time data update capability

Datavisor’s flexible API architecture supports real-time requests for customer profile and profile update events, thus enabling seamless monitoring and proactive alerting for all subsequent customer profile updates. In a standard real-time integration, Datavisor’s Detection API will be leveraged to assess risk on customer profile related events. For more detailed information regarding Datavisor API architecture, real-time requirements and detection outputs, please reference the Datavisor Technical Integration Guide.

 

Transaction Monitoring

Transaction data fields, as well as customer profile data fields associated with the transaction, is an important driver of DataVisor’s ability to identify and alert transaction fraud. This document serves as a general integration guideline for identifying transaction fraud. Our team will work with the specific client on more detailed integration options.

Transaction Data

Fields that are helpful for transaction data include:

Category	Data Field	Description	Required
Transaction Information	Transaction ID	Unique identifier of the transaction	X
	Debit/Credit	Is transaction a debit or credit for the customer	X
	Customer ID	Customer ID  of the originator of the transaction	X
	Account ID	Unique ID of the account	X
	Counterparty Full Name	Full name of the counterparty account, i.e. the other party of the transaction	X
	Counterparty Tax ID	Unique tax identifier of the other party, such as SSN / ITIN	X
	Counterparty customer ID	Customer ID of the other party of the transaction, if available
	Counterparty account number	Counterparty account number	X
	Counterparty routing number	Routing number of the counterparty account
	Originating country	Country where the transaction originates from	X
	Beneficiary country	Country where the transaction goes to	X
	Transaction type	Type of the transaction (e.g. ACH, cash, )	X
	Transaction datetime	Time of the transaction, including time zone	X
	Amount	Transaction amount	X
	Currency	Transaction currency	X
	Base currency	Base currency for the transaction
	...	Any Additional Transaction Info
Merchant Information	Merchant Name	Name of the merchant who’s customer performs the transaction	X
	Merchant Category	What category this Merchant comes under	X
	Merchant Location	Location of the Merchant	X
	Merchant URL	URL of the merchant who’s customer performs the transaction
	MCC1	Merchant Category Code 1
	MCC2	Merchant Category Code 2
	MCC3	Merchant Category Code 3
	...	Any Additional Merchant Information
Payment Information	Card Number	Card Number (Hashed is ok, with SHA-256 hashing)
	Card Last 4	Last 4 digits of the Card number (If card number is hashed)
	Card Name	Name on the Card (Hashed is ok, with SHA-256 hashing)
	Card Expiration	Expiration month of the card (MM/YYYY)
	BIN	BIN lookup value
	Billing Address Line 1	Billing Address provided by customer
	Billing Address Line 2	Billing Address 2 provided by customer
	Billing City	Billing City provided by customer
	Billing State	Billing State provided by customer
	Billing Country	Billing Country provided by customer
	Billing Zip	Billing Zip provided by customer
	...	Any Additional Payment Information
POS Terminal Information	POS Entry Mode	How the payment was initiated (i.e. swipe, insert, NFC, etc.)
	POS Terminal ID	Terminal ID for the POS system being used
	POS Device Type	POS device type
	POS Location	Location of the POS device
	...	Any Additional POS Terminal Information
Digital Information	Email	Email input by customer
	IP address	IP address associated with the transaction
	Phone	Phone number associated with the transaction
	Device type & version	Make and model of the device (e.g., Mac OS 10, iPhone 8)
	Device ID	The device fingerprint identifier for the account applicant’s device
	Operating system	The operating system and version of the device
	User agent	Incoming raw user agent string from the browser
	Browser cookie	The cookie of the browser
	Device name	The device name the account holder assigned to his/her device
	...	Any Additional Digital Information
Order Information	Order ID
	Order Item ID(s)
	Order Items category	Electronics, gift cards, resellable items, …
	Shipping Address Line 1	Shipping Address Line 1
	Shipping Address Line 2	Shipping Address Line 2
	Shipping Address City	Shipping Address City
	Shipping Address Zip Code	Shipping Address Zip Code
	Shipping Address State	Shipping Address State
	Shipping Address Country	Shipping Address Country
	Recipient Name	Recipient Name
	Recipient Phone	Recipient Phone
	Recipient Email	Recipient Email
	Delivery Instruction	Delivery Instruction e.g. “gate enter code 123”, “call me at XXX”
	..	Additional info about the order, the recipient, or the delivery details
Authorization Results	AVS Response Code	Response code received through Address Verification Services for Card Not Present scenario
	CVV Response Code	Response code for Card Verification Value
	ECI Response Code	2 or 3 digit Electronic Commerce Indicator (ECI) code returned by the issuing bank and credit card specific networks, if 3DS is implemented
	Gateway/Acquirer Response	Response code returned by the payment gateway Approved/Declined, Decline reason.
	...	Any Additional Authorization Results

 

Feedback Data

DataVisor system can take in fraud labels and review feedback for performance monitoring. Feedback can come in two forms: in-house case management feedback or API feedback. If client uses DataVisor’s case management to review case and file SARs, decisions will automatically be recorded in the system and no additional integration is needed. If feedbacks are generated in other systems, e.g., external case management system, customer reports, these data can be sent to DataVisor as feedback data. 

Fields that are helpful for feedback data include:

Category	Data Field	Description	Required
Transaction Information	Transaction ID	Unique identifier of the transaction	X
	Transaction datetime	Time of the transaction
	Customer ID	Unique identifier of the customer who performs the transaction
Case Information	Case ID	Unique identifier of the associated case	X
	Case creation date	Date of case creation time
Transaction Outcome*	Transaction outcome	Merchant decision for Approved, or declined.
Label  Feedback	Fraud label **	Whether the transaction is reported as fraud such as chargeback
	SAR label	Whether a case is reviewed as suspicious and a SAR is filed
	SAR filing datetime	Datetime when a SAR is filed
	Disposition label	Whether a case if reviewed as not interesting hence false positive
	Other label	Whether the transaction is confirmed as fraudulent/suspicious transaction for other reasons
Comments	Comments	Additional comments or meta data

 

* Transaction outcome should come in as a separate event to DataVisor Update API, if the auto decisioning logic is not implemented in DV platform.

** Fraud Label feedback should come in as a separate event to DataVisor Update API.

Please refer to DataVisor API Integration Guide for sending data events to DataVisor real time APIs and what API responses would be returned by the APIs.

Real time and batch based integration

DataVisor supports both real time and batch integration methods. 

Real time mode

Datavisor’s flexible API architecture supports real-time requests for transaction monitoring events, thus enabling real-time decisioning. In a standard real-time integration, Datavisor’s Detection API will be leveraged to assess risk at the transaction level. For more detailed information regarding Datavisor API architecture, real-time requirements and detection outputs, please reference the Datavisor Technical Integration Guide.

Batch Mode

Should you decide to integrate with DataVisor in batch mode, you have the option of managing the batch data transfer via a cloud storage provider (e.g. AWS S3). Please speak with your Technical Account Manager to determine which cloud provider best suits your institution.DataVisor supports all three major public clouds (AWS, GCP, Azure).

DataVisor provides two options for batch uploads, both of which can be automated to support daily / mini-batch uploads.

• Direct File Upload via Script
• SSH File Transfer Protocol (SFTP)

For Option 1, DataVisor provides Python scripts to ensure data security and to optimize large file transfer performance.

For Option 2, DataVisor will create a bucket that can be accessed by the client via SFTP after receiving a public key generated by the client (the private key is used client-side to access the same bucket and should NOT be shared with DataVisor).

Both our Feature Platform and Rule Engine fully support batch mode. Users can work with DataVisor to schedule the batch process frequencies and the data and rules to process during recurring batch run.

 

Historical Data Preparation

For a rapid start, DataVisor recommends a historical data set (3 months) for the purpose of building historical profiles for customers to establish a transaction baseline. The best practice is to send over a data struction report to the “Technical Account Manager” before sending the full historical data set over. This data structure report should contain the following information for each data set:

• Schema of each the data types
• Preview (10 rows) of  for each data type
• Earliest date and latest date in the historical data set provided
• Number of rows for the historical data set provided

 

Alert/case management and SAR filing configuration

Out-of-box AML Rules

As a quick start, DataVisor provides an out-of-the-box Transaction Monitoring Rule Package that covers most common AML scenarios. The rules and supporting features are hosted on our powerful Rule Engine and Feature Platform which allows easy testing and tuning without any coding. During the integration, DataVisor supports configurations of custom ML solutions aimed at smart segmentations, alert noise reductions, proprietary UML technology to uncover fraudulent clusters, etc.

Workflow Configuration

DataVisor Case management system allows flexible workflow configurations including case status, case routing, actions, and checklists. In addition, DataVisore is currently developing capabilities for automatic SAR filing. It is expected to be launched in two quarters based on the product roadmap