The raw data files (RDFs) 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.
RDFs are securely delivered each day. With the RDFs 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 standard suite of RDFs includes:
- 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
In addition to RDFs you can receive custom data files (CDFs). A few of the most commonly requested CDFs are:
- Chargebacks and Disputes — Enhanced chargeback and dispute data beyond what the Posted Transactions RDF shows.
- Overdraft — Enhanced overdraft data beyond what the Posted Transactions RDF shows.
- Authorization Expiries — Unsettled authorizations that have expired from the authorization database.
If you need other data sets from Galileo, you can arrange for those files to be generated and made available through the same method as the RDFs.
RDFs and CDFs are available in ProductionProduction - The live Galileo environment where real transactions are performed. but not in CVCV - Client Validation. A test environment where you can test your implementation before moving it to Production..
Galileo has sample RDFs that you can see for example values and formats. In addition, you can ask for the Card Transaction Scenarios PDF from Galileo to see examples of how different transaction types are represented in the RDFs.
The RDFs are generated early every morning and contain activity from the previous calendar day, which on the Galileo system is from 00:00:00 (midnight) to 23:59:59 Arizona time (GMT -0700), a time zone that does not observe daylight saving time.
- Because many different files are generated 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, custom data files (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. Coordinate with Galileo to get an account name and password.
RDF names have this format. The date represents the day when the file was generated, so a file that is dated
20211010 contains data from October 9, 2021:
The files are PGP-encrypted using your public PGP key. RDFs are fixed-width files, which means that each field takes a fixed amount of space, including trailing spaces to pad out the field. CDF format varies by file: many are fixed-width, but some files, such as Secondary Accounts and Overdraft, are comma-separated values (CSVs). Galileo will provide 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 G-Analytics (Galileo Analytics) tool. Only the standard RDF layouts are available in G-Analytics.
If there is no activity in your program during a calendar day, you will receive RDFs that contain headers and footers but no records.
If there is a system or connectivity failure that prevents the RDFs from being delivered at the usual time, the RDFs will be delivered as soon as it is possible instead of waiting until the next day.
Some of the fields contain PCI-sensitive information. 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:
ID 2, when
ID TYPE 2is SSN (Social Security number)
DATE OF BIRTH
Galileo strongly recommends that you use the RDFs to create a datastore of transactions and customer records that is separate from the production database that you create from the Events API or Program API. (For more information on building a production database see the Transaction History 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 the live production environment.
- Produce longer-term transaction histories in your app or on your website instead of costly endpoint calls to Get Transaction History or other Program APIs.
Because RDFs are daily differential files instead of complete histories, you can read RDFs 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.
With each RDF in its own table you can perform complex queries. If you need to join two tables in a query, join on these two fields:
UNIQUE PROGRAM ID
GALILEO ACCOUNT ID
On every statement cycle date, use your Posted Transactions RDF datastore to produce a list of all transactions during the billing period as well as make interest calculations.
If you want to show pending authorizations as of the statement date, compare the list of transactions in the Authorized Transactions RDF with the Posted Transactions RDF using
AUTHORIZATION CODE +
NETWORK CODE to match transactions. Any unmatched authorizations during your selected timespan can be displayed as pending.
When assembling statements from the RDFs, keep the following in mind:
- Consult with your bank to obtain all of your statement requirements.
- No single RDF file contains all of the data to use for a statement: You must draw on the datastore that you have accumulated from daily RDFs.
- A Galileo calendar day may not correspond to the day that you use for statements. For example, if you are in the U.S. Eastern time zone (GMT -0500), your day begins two hours earlier than Galileo's day during standard time and three hours earlier during daylight saving.
- In most cases, banks require you to store statement data for seven years.
- Interest-bearing accounts must report interest on a monthly basis, not a bill-cycle basis.
- Where there is more than one account or card per balance ID (
GALILEO ACCOUNT ID), the statement can break out transactions per card.
- As desired, you can break out transactions per merchant category code (MCC).
- Amounts are always in the currency in which the account is based. Card networks automatically convert foreign currency amounts (both authorizations and settlements) into the account's local currency.
- You can differentiate between network and non-network transactions using the
TRANSACTION TYPE/CODEfield. Network transaction types are listed in the Transaction Types enumeration.
- Except by request, the RDFs do not include the transaction description that was used by the Create Account Transfer, Create Payment, or Create Adjustment endpoints. You may want to set up your own lookup file to correlate transaction types with descriptions.
Consult RDF Reference for individual field descriptions as well as other details about each RDF.
Updated 12 days ago