The raw data files (RDFs) and custom data files (CDFs) are text files that you receive from Galileo once per day. These files contain low-level extracts of the prior day’s activity from Galileo's databases.

The files are securely delivered each day. With the raw data you can build your own data store to compare with your production database, build statements and reports, and provide your customers with long-term transaction histories.

The RDFs comprise a standard suite that is offered as a unit:

  • **Customer Master** — A list of primary accounts, their balances, and customer information

  • **Account Card** — A list of cards issued

  • **Authorized Transactions** — Authorization activity

  • **Posted Transactions** — Settlements, payments, adjustments, and fees

  • **Lookup** — A lookup file for the other RDFs

Currently, the default suite of RDFs is called the "secondary" or "full-width" RDFs. (The other RDFs historically were the defaults.) See <a href="doc:secondary-rdf-reference" target="_blank">Secondary RDF Reference</a> for a list of the fields for each RDF.

You can also request one or more CDFs:

  • **Authorization Expiries** — Unsettled authorizations that have expired from the authorization database

  • **Early ACH** — ACH details as well as number of days early the transaction posted

  • **ACH Returns** — Details on returned ACH transactions

  • **Incoming ACH** — Details on incoming ACH transactions

  • **Overdraft** — Enhanced overdraft data beyond what the Posted Transactions RDF shows

  • **Settlement** — Similar to the _Settlements - Bin Summary_ report in gAnalytics, this data looks back one day for Visa, Mastercard and Discover, three days for Maestro/Cirrus, and two days for Pulse, Allpoint and Star. In contrast, the gAnalytics report looks back one day for all networks.

  • **Mastercard SAFE Report** — The SAFE report that was sent to Mastercard over the last seven days

  • **Chargebacks and Disputes** — Enhanced chargeback and dispute data that is similar to the _Dispute Tracker Log_ in gAnalytics.

  • **Direct Deposit Switch** — Details of direct-deposit switch setups for the day

  • **B2B Customer Master Supplemental** — The relationship between Real-Time Funding or Corporate Credit spending accounts and their respective funding accounts.

  • **MSI Installments** — Details on MSI Installments

  • **Bad PAN Authorizations** — Attempted authorizations on your BIN for cards that do not exist

  • **Fleet Data** — L2 and L3 data specific to fleet-card purchases.

  • **Other data** — Any specialty data sets that Galileo can set up for you.

See <a href="doc:cdf-reference" target="_blank">CDF Reference</a> for a list of the fields for each file.

Note

RDFs and CDFs are available in <<glossary:Production>> but not in <<glossary:CV>>.

Galileo has sample RDFs that you can see for example values and formats. CDF samples are not available. In addition, you can consult the <a href="page:card-transaction-scenarios-index" target="_blank">card transaction scenarios</a> to see examples of how different transaction types are represented in the RDFs.

## Accessing the files

The RDFs and CDFs are generated early every morning and contain activity from the previous calendar day, which is from 00:00:00 (midnight) to 23:59:59 <a href="ref:galileo-system-time" target="_blank">Galileo system time</a>.

  • Because Galileo generates many different files every day, availability times are staggered throughout the morning. Consult with Galileo for the times when you can expect your files to be ready.

  • On days when maintenance upgrades are performed, the availability time may be delayed.

  • In general, CDFs are available a few hours after the RDFs.

Galileo uses Secure File Transfer Protocol (SFTP) to deliver RDFs and CDFs. You can arrange to retrieve the files from Galileo's SFTP server or Galileo can push the files to your SFTP server. Connections are secured using SSH keys.

RDF and CDF filenames contain a date, formatted as `yyyymmdd` or `%Y%m%d`. The date represents the day when the file was generated, so a file that is dated `20231010` contains data from October 9, 2023. The precise filename format is provided in the reference section for each file, such as the <a href="doc:cdf-reference#early-ach-cdf" target="_blank">Early ACH CDF</a> section in the _CDF Reference_.

  • The files are PGP-encrypted using your public PGP key.

  • The standard RDFs are fixed-width files, which means that each field takes a fixed amount of space, including trailing spaces to pad out the field.

  • Secondary RDFs and CDFs are comma-separated value files (CSVs).

  • For the standard RDFs, Galileo provides you with a document that specifies the layouts for your program, including field sizes and data types. You can also access the latest version of your RDF layouts from the gAnalytics (Galileo Analytics) tool. Only the standard RDF layouts are available in gAnalytics.

  • The layouts for the other files are available in the <a href="doc:cdf-reference" target="_blank">CDF Reference</a> and the <a href="doc:secondary-rdf-reference" target="_blank">Secondary RDF Reference</a>.

  • By default, Galileo consolidates all of your programs into one file. You can also request that Galileo create one file for each `UNIQUE PROGRAM ID`, with extra setup work.

### Exceptions

  • If there is no activity in your program during a calendar day, you will receive files that contain headers and footers but no records.

  • If there is a system or connectivity failure that prevents the files from being delivered at the usual time, the files will be delivered as soon as it is possible instead of waiting until the next day.

  • If there is a problem with the files, and a corrected file must be sent, Galileo will notify you through established channels what the corrected filename is.

## PCI compliance

Some of the fields contain <a href="doc:pci-sensitive-data" target="_blank">PCI-sensitive information</a>. If you are PCI compliant, you have the option of requesting that these values be masked or replaced by spaces. If you are not PCI-compliant, these values will be replaced by spaces:

  • `CARD NUMBER` (PAN)

  • `ID` or `ID 2`, when `ID TYPE` or `ID TYPE 2` is SSN (Social Security number)

  • `DATE OF BIRTH`

## Building a datastore

Galileo strongly recommends that you use the RDFs to create a datastore of transactions and customer records that is separate from the production or caching datastore that you create from the Events API or Program API. (For more information on building a caching database see the <a href="doc:transaction-history" target="_blank">Transaction History</a> guide.)

Use the RDF-based datastore to:

  • Ensure that there are no missing or incorrect transactions in your production database. Where there are discrepancies between the RDFs and your records, you should consider the RDFs to be authoritative.

  • Run reports and perform data analysis, where large queries would overly tax your live production environment.

  • Produce longer-term transaction histories in your app or on your website instead of using costly endpoint calls to <a href="ref:post_gettranshistory" target="_blank">Get Transaction History</a> or other Program API endpoints.

Use the CDF-based datastore to add details to the transactions in the Posted Transactions RDF, such as overdraft, ACH and expired authorizations.

Tip

Because RDFs and CDFs are daily differential files instead of complete histories, you can read the files into your own data histories every day, which allows you to maintain a complete history by stitching together each day’s changes.

Keep in mind that when you are the system of record, the Galileo system may not have all of your transactions, depending on which transactions you report to Galileo. For example, Galileo may not have your card loads or other deposits.

### Performing queries across tables

With each RDF in its own table you can perform complex queries. If you need to join two RDF tables in a query, join on these two fields:

  • `UNIQUE PROGRAM ID`

  • `GALILEO ACCOUNT ID`

When joining CDF-based tables, select fields that uniquely identify the account or transaction:

  • `auth_id` + `network_code` uniquely identifies card transactions

  • `pmt_ref_no` uniquely identifies an account

  • `bal_id` uniquely identifies balances, though you should keep in mind that multiple accounts can transact on the same balance

## Building statements

See <a href="doc:creating-statements-from-the-rdfs" target="_blank">Creating Statements from the RDFs</a> for instructions on using your RDF datastore to build customized statements for your customers.

## Field descriptions

Consult <a href="doc:rdf-reference" target="_blank">RDF Reference</a>, <a href="doc:secondary-rdf-reference" target="_blank">Secondary RDF Reference</a>, or <a href="doc:cdf-reference" target="_blank">CDF Reference</a> for individual field descriptions as well as other details about each file.