Data Requirements

Abstract

This document outlines the data sharing requirements for Publisher Partners working with Cardlytics to facilitate a robust offers and cash-back experience for customers. It details the types of data feeds, the scope of data, and the specific data fields required for historical and daily transaction data, as well as customer and account data.

Overview

Purpose of Data Sharing

Cardlytics requires Publisher Partners to share customer, account, and transaction data to enable personalized and effective cashback offers for customers.

Types of Data Feeds

Historical Data Feeds: A 12-month "look-back" dataset is required before the program launch to target customers based on past behavior.
Daily Data Feeds: Continuous data updates are necessary to support ongoing operations.

Data Scope

Data pertains to current eligible customers and open accounts only.

Key Data Requirements

Customer and Account Data:
- Unique customer and account identifiers (e.g., sourceCustomerId, sourceAccountId).
- Additional attributes such as postal code, country, and portfolio ID to maintain accurate customer profiles.
- Customer data is designed to protect consumer privacy by avoiding direct exposure of actual customer numbers.
Transaction Data:
- Detailed transaction information (e.g., transactionId, transactionType, authorizationAmount).
- Merchant-related fields such as category codes, merchant name, city, and postal code.
- Timestamp fields to record transaction occurrence and posting times.
- Currency and transaction amounts are standardized for consistency.

Summary of Requirements

All required fields are clearly defined with examples and formatting instructions.
Privacy considerations are emphasized, ensuring unique identifiers are used without exposing sensitive customer or account information.

Types of Data Feeds

Two primary types of data feeds are utilized:

Historical or “look-back” data: This data is loaded prior to the "Go Live" date and enables the targeting of customers with relevant offers based on their past spending behavior.
Daily data feeds: These feeds support the continuous operation of the Cardlytics system.

Historical Transaction Data

An initial export of 12 months of historical transaction data is necessary to enable effective targeting at program launch for all eligible customers.

Customer and Account Data

Specific customer and account data is required to create and maintain accurate customer profiles within the Cardlytics platform. Detailed requirements for each data field are outlined in the provided tables.

FIELD	DESCRIPTION	REQUIRED	EXAMPLE
sourceCustomerId	Unique ID for the customer - Should not be the actual customer number to protect consumer data. The financial institution will need to be able to match this number to the actual customer number to resolve service issues. This value is immutable once set -- it cannot be changed via any process.	Yes	"afa2r21-25f9-4501-b9db-e78afa73c0e3”
organizationId	ID of a subsidiary of an institution.	Yes	01
postalCode	The postal code of the customer. US: 12345-6789 or 12345 UK: KT6 3 (Ex CAN)	Yes	”78732”
country	COUNTRY CODE, ISO 2 digit country code	Yes	“US”
Account(s)
sourceAccountId	Unique ID for an account - Should not be an actual account number to protect consumer data. The financial institution will need to be able to match this number to the actual account number to resolve service issues. This value is immutable once set -- it cannot be changed via any process.	Yes	"42c57311-25f9-451-b9db-e78afa73c0e3"
sourceCustomerId	Unique identifier for all customers associated with the account	Yes	“afa2r21-25f9-4501-b9db-e78afa73c0e3"
SourcePortfolioId	Source portfolio id to which account is enrolled.	Yes	“2034”

Transaction data

Detailed transaction data for card/account purchases is essential for precise targeting and redemption of customer offers. Specific requirements for each data field are outlined in the provided tables.

FIELD	DESCRIPTION	REQUIRED	EXAMPLE
transactionId	Unique transaction ID from the network or a unique ID for the transaction from the financial institution. Several fields can be concatenated to make this field truly unique (e.g. unique ID + date-time stamp + amount).	Yes	“8179bea8-0d04-4d2b-bd78-b1ffbad3ec48,”
transactionType	Indicates whether transaction is of type: "AUTHORIZED", "CLEAR", "RETURN", "CHARGEBACK"	Yes	“Debit”
sourceAccountID	Unique identifier of the account associated with the card	Yes	“afa2r21-25f9-4501-b9db-e78afa73c0e3"
sourceCustomerId	Unique identifier for all customers associated with the account	Yes	“afa2r21-25f9-4501-b9db-e78afa73c0e3"
transactionTimestamp	The date/time the transaction occurred using the local time where the purchase was made with offset to UTC (z, +2, etc). Please do not include any special characters. Format ISO 8601	Yes	“2023-06-01 222157”
transactionPostingTimestamp	The date/time the transaction cleared (Local time with an offset to UTC (z, +2, etc)). Do not include any special characters. Format ISO 8601	Yes	“2023-06-01 222157”
paymentNetworkMCC	4 digit merchant category code (MCC)	Yes	“5432”
paymentNetworkMerchantIdType	Describes the payment network merchant type	Yes	MID, CAID,VSID,SE
paymentNetworkMerchant	Name of the merchant (full information passed)	Yes	“lululemon”
paymentNetworkMerchantCity	City where the purchase was made	Yes	“Austin”
paymentNetworkMerchantState	Abbreviation of the state or province where the purchase was made UK: City and state are the city.	Yes (Not valid in UK)	“Texas”
paymentNetworkMerchantPostal	Purchase Postal Code – May be listed as the city code in the transaction record.	Yes	“SE1 7ND”
paymentNetworkMerchantId	Merchant number contained in the network transaction record (sometimes called Field 42 Card Acceptor ID)	Yes	“93A934954789”
authorizationAmount	The amount of the transaction at time of authorization (or swipe). The system will assume the last two digits represent ‘cents’, so do not round off trailing zeros (i.e. $5.00 = 500)	Yes	“2500”
postedAmount	The amount of the posted transaction. Do not include the decimal point. The system will assume the last two digits represent ‘cents’, so do not round off trailing zeros (i.e. $5.00 = 500)	Yes	“2500”
currencyCode	Standard network currency code (i.e., $US = USD or 840)	Yes	“USD”