Data Integration Guide - ACH Transfers

 

ACH Transaction Data for Analysis

Transaction data fields, as well as customer profile data fields associated with the transaction, are an important driver of DataVisor’s ability to identify transaction fraud in ACH transfers. Sensitive customer PII information is not required for our ability to detect. This document serves as a general integration guideline for identifying ACH fraud. Our team will work with the specific client on more detailed integration options.

ACH Transaction Data

Fields that are helpful for transaction data include:

Category	Data Field	Description	Required
Account linkage	Internal account number	Unique internal account number (can be hashed)	X
	Internal customer ID	Unique internal customer ID	X
	External acct routing number	Routing number of the linked external account	X
	External acct number	Account number of linked external account (can be hashed)	X
	Authentication method	Method used to authenticate the external account ownership, possible methods are. trial deposit, instant authentication via login, authentication through EWS AOA, ect	X
	Status	External account linkage result	X
EWS AOA	Internal account number	Unique internal account number (can be hashed)
	Internal customer ID	Unique internal customer ID
	External routing number	Routing number of the linked external account
	External account number	Account number of linked external account (can be hashed)
	EWS AOA matching score	Overall matching score of inquired account ownership
	Last name matching results	Account owner last name match result
	First name matching results	Account owner first name match result
	SSN matching results	Account owner SSN name match result
	External account status	Status of the inquired external account
ACH transaction	Internal account number	Unique internal account number (can be hashed)	X
	Internal customer ID	Unique internal customer ID	X
	ODFI_RDFI indicator	Initiation party of the ACH transaction	X
	Debit/Credit	Is ACH a debit or credit for the internal account	X
	Amount	Transaction amount	X
	External account routing number	Routing number of the linked external account	X
	External account number	Account number of linked external account (can be hashed)	X
	Entry date	Date the ACH transaction is created	X
	Effective date	For scheduled transaction, the date ACH transaction is scheduled for
	Transaction CD	standard ACH transaction code	X
	Return CD	For returned ACH, the return reason code	X
	ACH transaction ID	Unique ACH transaction ID	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
ACH Transaction Outcome	ACH Return Label	Whether the ACH is Returned	X
	ACH Return Code	ACH Return Code	X
	Fraud Return or Not	Should this ACH return be treated as Fraud by DV system

An example of transaction data:

Transaction ID	Account ID	Transaction Type	Transaction Time	Amount	External Account Number	...
1203029281904	53277897	ACH	2016-08-16 12:35:06	88.4	42298131	...
9303283057123	40098005	ACH	2016-08-16 12:35:06	837.43	20381047	...

Customer Profile Data

Customer profile data is also important for fraud detection, when merging with transaction level data.DataVisor uses various types of at-rest and in-transit encryption methods to make sure the PII data shared in the customer profile data is handled in a secured way. If PII data sharing is not available, we recommend using SHA-256 hashing to hash the data before sharing the customer profile data with DataVisor.

Fields that are helpful for customer profile data include:

Category	Data Field	Description	Required
Customer Profile Data	Customer ID	Unique identifier of the customer who performs the transaction	X
	Registration time	The time the user first registered in the platform	X
	Product type	The type of product customer has	X
	Customer tenure	Tenure of the customer
	Email	Email address of the customer	X
	Phone	Phone number of the customer, or phone prefix
	Full Name	The full name of the customer	X
	Address	The address of the customer
	Country	The country 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
	Year of Birth	Year of birth of the customer
	Annual Income	Annual income of the customer
	Employer	Employer name of the customer

An example of customer profile data:

Customer ID	Name	Customer Tenure	Product Type	Email	Registration Time
53277897	Alice Jane	14 months	Premier Credit Card	[e-mail]	2014-01-01 12:03:03
40098005	John Doe	60 months	Premier Credit Card	[e-mail]	2017-01-02 12:00:00

Data Structure Report

Before sending the full data over, please send over a data structure report to your Technical Account Manager. This process allows DataVisor to ensure a faster turnaround time and a higher quality of results during the fraud assessment. This data structure report should contain the following for each data set:

• Schema
• Preview of 10 rows
• Earliest date and latest date (If there is an associated timestamp)
• Number of rows

Data Anonymization

DataVisor’s algorithm is able to work with anonymized data fields if required. For sensitive PII information, such as name and address, anonymized information can be processed by our algorithm as long as the data structure remains.

Choosing a Connection Type: Batched or Real-time data transfer

For a batch data transfer, the client sends data in bulk to DataVisor. The frequency of batch data transfer is determined by client’s use case and business requirements. Batch transfers are faster to implement, as they don’t require an integration with DataVisor’s APIs. Account application data should be given as is at the end of the batch time period, and included in the batch. 

Real-time data connection

For a real-time data connection, the client integrates DataVisor’s APIs to send a real-time stream of data. After a ~2 week observation and tuning period, DataVisor returns real-time results, which can be used as an additional signal in the client’s fraud detection infrastructure. All account application data should be uploaded at the beginning of the fraud assessment. 

Formatting and transferring data

Formatting Data

DataVisor can accept data in the following formats:

1. JSON (preferred) 
2. Tab Delimited
3. CSV

For other formats, like TXT or report exports, please contact your Technical Account Manager.

Example JSON format: 

{"txn_id":1203029281904, "customer_id":53277897, "txn_type":"Online", "event_time":"1423160520015", "time_zone":"UTC+0200", "amt":88.4, "txn_recipient":"Amazon Inc"}

Data Labels

Data labels are metadata that indicate which accounts are confirmed to be fraudulent. Although not required for DataVisor’s unsupervised technology, labels can be helpful to gauge results. If you have labels available, your DataVisor Technical Account Manager can help you determine whether it would be worthwhile providing them for the fraud assessment.

Transferring Data

DataVisor’s fraud detection solution can be deployed on-premise or in a cloud environment. For on-premise deployment, please contact us for customized data transfer details.

For cloud deployment, DataVisor will create an Amazon S3 bucket exclusively for you to ensure your data’s privacy. A customized python script will be provided to securely upload data to this bucket.