Product RDFs

The Product RDFs contain data for specific Galileo products. These RDFs used to be called CDFs. Other former CDFs are now classified as Service RDFs.

See About the Raw Data Files (RDFs) for general information on these files.

• Overdraft Details — Information related to overdraft accounts and transactions.
• Early ACH — Data for incoming ACH credit transactions that were posted early, along with the number of days they were posted early.
• ACH Returns — Data on ACH transactions that were returned on the previous day.
• Incoming ACH — Data on all incoming ACH transactions for the prior day, including both ACH debits and ACH credits.
• ISS — Data on savings account interest accrual, interest year-to-date, and annual percentage yield earned for a savings account
• Frequent Disputer — Dispute-related data on individual accounts, including statistics on dispute frequency and funds lost and won.
• Direct Deposit Switch — Data on direct deposits set up using the switch.
• B2B Customer Master Supplemental — Showing which RTF or Corporate Credit funding accounts are linked to which spending accounts.
• MSI Installments — Data on MSI installments, a Mexico product.
• Bad PAN Authorizations — Authorization requests from card numbers with your BIN, but the PAN does not exist in the Galileo system.
• Fleet Data — Data on all transaction activity of fleet-card profiles along with additional level 2 and 3 data.

Overdraft Details RDF

The Overdraft (OD) Details RDF provides information related to overdraft DDA accounts for prior days.

This table contains default fields for the OD RDF.

• The primary key for this file is GPR_XID.
• The filename format is od_details_DDA_%Y%m%d.csv.

Back to top

Early ACH RDF

The Early ACH RDF provides data for incoming ACH credit transactions that were posted early, along with the number of days they were posted early. You can use this data to analyze the benefit of using early ACH as a service and for your reconciliation needs. Because early ACH applies to incoming ACH transactions, you can also see these transactions in the Incoming ACH RDF.

Insights for you

• In conjunction with other RDFs, correlate the effects of early ACH on driving spend
• Identify changes in direct-deposit enrollment rate.

This table contains standard fields for the Early ACH RDF.

• The primary key for this file is Transaction ID.
• The filename format is early_ach_report_%Y%m%d.csv.

Back to top

ACH Returns RDF

The ACH Returns RDF provides data on ACH transactions that were returned on the previous day. This data helps you keep track of your ACH return rates—if you have unusually high return rates, your program could be scrutinized by the ACH Operator.

Insights for you

• Identify the reasons for high return rates and develop a plan in place to address it
• Identify potential fraudulent ACH activity based on return codes

This table contains default fields for the ACH Returns RDF.

• The primary key for this file is TransID.
• The filename format is ach_returns_report_%Y%m%d.csv.

Back to top

Incoming ACH RDF

The Incoming ACH RDF provides data for all incoming ACH transactions for the prior day, including both ACH debits and ACH credits. This file helps you reconcile ACH transactions.

This table contains default fields for the Incoming ACH RDF.

• The primary key for this file is Authorization Code + Transaction Type.
• The filename format is incoming_ach_report_%Y%m%d.csv.

Back to top

ISS RDF

The ISS RDF contains data about rates and accumulated interest for savings accounts.

This table contains default fields for the ISS RDF.

• The primary key for this file is SAVINGS_ACCOUNT_ID.
• The filename format is TBA.

Back to top

Frequent Disputer RDF

This table contains default fields for the Frequent Disputer RDF.

• The primary key for this file is XID or PMT_REF_NO.
• The filename format is TBA.

Back to top

Direct Deposit Switch RDF

The Direct Deposit Switch RDF provides data on direct deposit switch transactions.

This table contains default fields for the Direct Deposit Switch RDF.

• The primary key for this file is galileo_guid.
• The filename format is ddswitch_trans_%Y%m%d.csv.

Back to top

B2B Customer Master Supplemental RDF

The B2B Customer Master Supplemental RDF shows the relationship between Real-Time Funding or Corporate Credit spending accounts and their respective funding accounts. It also provides balances for the funding accounts.

• The primary key for this file is PRN or XID.
• The filename format is b2b_custmaster_supplemental_%y%m%d.csv

Back to top

MSI Installments RDF

The MSI Installments RDF contains information about MSI Installments. Only transactions related to MSI Installments are included in this file.

• The primary key for this file is UNIQUE PROGRAM ID + AUTHORIZATION CODE + TRANSACTION CODE/TYPE.
• The filename format is Installments_Posted_Trans_[clientname]_%Y%m%d.csv
• The Source column indicates where the value came from: Galileo, a Nacha file, a private data subelement (PDS) from a network settlement file, or a data element (DE) in the ISO 8583 message in the authorization stream. The actual element/subelement number for a field may vary by network, and not all elements/subelements are present for all networks.
• "Signed" amounts have a - sign for debits and no sign for credits: -30.25 for a debit and 23.67 for a credit.
• All DATETIME fields are YYYY-MM-DD h24:mm:ss.

Back to top

Bad PAN Authorizations RDF

The Bad PAN Authorizations RDF contains a list of authorization requests from card numbers with your BIN, but the PAN does not exist in the Galileo system. These attempted transactions could be fraudulent.

• The primary key for this file is AUTHORIZATION CODE.
• The filename format is [client]_badpan_authorizations_%Y%m%d.csv
• "Signed" amounts have a - sign for debits and no sign for credits: -30.25 for a debit and 23.67 for a credit.
• All DATETIME fields are YYYY-MM-DD h24:mm:ss.

Back to top

Fleet Data RDF

The Fleet Card RDF provides data on all transaction activity of fleet-card profiles along with additional level 2 and 3 data. This file can be used to predict transaction volume and interchange revenue by forecasting driver spend, expected fuel refill timing and transaction amount. Additionally, you can identify any dormant fleet cards, monitor for any fraudulent transactions outside of normal fleet-card operations, utilize fleet-card data to develop spend and driver controls, etc. This RDF also contains specific data that will help provide insights to corporate customers of driver spend patterns, vehicle usage, and budgeting recommendations.

Insights

This file provides key insights for both you and your business customers. For example, it helps you calculate the AMPG:

AMPG = (current odometer reading (PDS 0629) – previous odometer reading) / (previous number of fuel gallons purchased (PDS 0643))

Insights for your business customers

• Vehicle lifetime value
  • Average vehicle lifetime mileage
  • Percentage each vehicle has reached
• Driver performance
  • AMPG per driver
• Budgeting
  • ((driver AMPG) x (number of fuel gallons filled)) / (miles driven per day) = predict when the driver will refuel next

Insights for you

• Number of inactive fleet cards that you deactivate to save costs
• Identify and block atypical transactions based on driver's spend history
• Provide rewards and promote stickiness utilizing fuel company brand data
• Forecast revenue using frequency of driver refueling events and average spend.
  Expected monthly interchange = (interchange %) x (average cost of fuel refill) x (days in month) /(((AMPG) x (number of fuel gallons purchased)) / (miles driven per day))

File information

• The filename format is fleetfile_%Y%m%d.csv.
• See Fleet Cards for more information about the product.
• To interpret the codes in the fields, obtain the IPM Clearing Formats guide from Mastercard.
  For this RDF, three or more addendum rows are provided per transaction, according to this criteria
• Row 1 — Corporate card common data. Provided when the associated first presentment/1240 message meets all of these conditions:
  • The product is any corporate product.
  • The card acceptor country code (DE045 subfield 6) is "USA".
  • The cardholder transaction type (DE003 subfield 1) is 00 (purchase) or 18 (unique).
  • The transaction is not a reversal.
• Row 2 — Corporate fleet transaction information. Provided when the associated first presentment/1240 message is a Mastercard Corporate Fleet Card transaction for a fuel or non-fuel purchase.
• Rows 3–n — Corporate line-item detail. Provided when non-fuel items are purchased alongside fuel, using a fleet card.

The corporate line-item detail is provided for each additional non-fuel item purchased using a fleet card, so if a cardholder purchases five items in one transaction, the RDF will contain seven rows: one common data requirements row, one fleet transaction information row and five detail addendum rows. All rows that belong to the same transaction will have the same auth_code + network_code.

The auth_code + network_code is the foreign key to the associated financial transaction in the Posted Transactions RDF, matching the AUTHORIZATION CODE and NETWORK CODE fields in the RDF.

All rows

This table contains fields that are present in all row types.

Example

The three addenda types will be denoted as follows, assuming the purchase of three items:

Row 1: Corporate card common data requirement
usage_code: 98
industry_red_no: 000
occurrence_ind: 001

Row 2: Corporate fleet transaction info
usage_code: 98
industry_rec_no: 002
occurrence_ind: 001

Row 3: Corporate line-item detail
usage_code: 98
industry_rec_num: 950
occurrence_ind: 001

Row 4: Corporate line-item detail
usage_code: 98
industry_rec_num: 950
occurrence_ind: 002

Row 5: Corporate line-item detail
usage_code: 98
industry_rec_num: 950
occurrence_ind: 003

Row 1 fields

These fields will be inside the corporate_card_detail field in a row that has industry_rec_no: 000. All of the top-level fields will be present, even if the value is Null.

Example

{
    "card_acceptor_type":{
   	 "_raw":"1000YNNN",
   	 "business_type":"1",
   	 "business_owner_type":"0",
   	 "business_cert_type":"0",
   	 "business_eth_type":"0",
   	 "business_type_code":"Y",
   	 "business_owner_type_code":"N",
   	 "business_cert_type_code":"N",
   	 "business_eth_type_code":"N"
   	 },
    "card_acceptor_tax_id":{
   	 "_raw":"830197092  		 Y",
   	 "tax_id":"830197092  		 ",
   	 "tax_id_code":"Y"
   	 }
  }

Row 2 fields

These fields will be inside the fleet_detail field in a row that has industry_rec_no: 002. All of the top-level fields will be present, even if the value is Null.

Example

{
    "oil_company_brand_name":"9999",
    "purchase_time":"0809",
    "motor_fuel_service_type":"1",
    "motor_fuel_information":{
   	 "_raw":"00300000000409910002422000000000992",
   	 "motor_fuel_product_code":"003",
   	 "motor_fuel_unit_price":"000000004099",
   	 "motor_fuel_unit_of_measure":"1",
   	 "motor_fuel_quantity":"000242",
   	 "motor_fuel_sale_amount":"000000000992"
   	 },
    "odometer_reading":"0001000",
    "vehicle_number":"5369569",
    "driver_number":"1234  ",
    "product_type_code":"1"
}

Rows 3-n fields

These fields will be inside the line_item_detail field in a row that has industry_rec_no: 950. All of the top-level fields will be present, even if the value is Null.

Example

{
    "product_code":"5693655016",
    "item_description":"Coca Cola Soda",
    "item_quantity":{
   	 "_raw":"0000000000010",
   	 "quantity":"000000000001",
   	 "quantity_exponent":"0"
   	 },
    "item_unit_of_measure":"23",
    "item_unit_price":{
   	 "_raw":"0000000003990",
   	 "unit_price":"000000000399",
   	 "unit_price_exponent":"0"
   	 },
    "extended_item_amount":{
   	 "_raw":"00000000029912",
   	 "extended_amount":"000000000299",
   	 "extended_amount_exponent":"1",
   	 "extended_amount_sign":"D"
   	 },
    "debit_or_credit_indicator":"D"
}

Back to top