/
15 minute read
November 3, 2021

Reports In-depth

Hidden

The following sections provide detailed reporting information, including expected data refresh timelines, settlement timing, and detailed information on individual reports, including:

  • Balance

  • Card transactions

  • Other transactions

  • Credit

  • Program Stats

  • Risk management

  • Utilities

Expected refresh and settlement timelines

The following sections provide details on data refresh and settlement timelines.

Expected data refresh times

The following table shows the start and expected completion times for Coordinated Universal Time (UTC).

Data Run Description Start Overall Complete

Morning

Morning run that includes all data since prior run.

3:00 PM UTC

8:00 PM UTC

Afternoon

Mid-day run that includes all data since prior data run.

10:45 PM UTC

4:00 AM UTC

Overnight (Prior Data Run)

Prior day UTC data.

8:45 AM UTC

1:00 PM UTC

The 3:00 pm sync time reconciles the previous day’s activities, and is useful for comparing the prior day’s activity with today’s.

Settlement timing

The following time windows are applicable for US clients using the default network timing options.

Network Settlement Cut-off Time Payment Timing

VISA (VisaNet, Interlink, PLUS)

1:00 PM UTC

Business days only
8:30 PM UTC

Mastercard

4:00 PM UTC

Business days only
10:00 PM UTC
(To include Sundays beginning in October, 2021)

Maestro (Domestic PIN Debit)

9:00 AM UTC

Business days only
10:00 PM UTC

Maestro (Cross Border PIN Debit)

10:00 AM UTC

Business days only
10:00 PM UTC

Pulse

8:00 AM UTC

Business days only
10:30 PM UTC (T+1)
Fees and disputes: (T+2)

Balance

Balance reports calculate balances, often at a day-level granularity. Balances are aggregations of funds in vs funds out at various granularity levels such as a cardholder or a program at a snapshot in time. Balances calculate activity over all time.

Overview
  • Day

  • Acting Cardholder

  • Amount to Send

Day

The Balance — Overview/Day report provides a daily snapshot of a program’s activity. This report includes total all-time cardholder balances for both the start of the day and the end of the day (starting balance and ending balance), along with activity (spend and loads) that are the components of cardholder balances.

The report provides a single row per day per program, but is split by currency so you can have multiple entries for the same day if there are two settlement currencies.

Note
The starting and ending balances are net cardholder balances (loads vs spend). These are not program funding balances. If your program has fully implemented JIT, the expectation is that these will be $0.

The Marqeta_Funds_Loads_Net field tracks a type of load associated with pre-load programs where Marqeta has loaded funds on behalf of the program. This field is typically not relevant for JIT programs, although this may be relevant for current JIT programs if it was transitioned at some point from pre-load to JIT.

Loads versus spend

The following columns are considered Loads:

  • credit_or_debit_card_loads_net

  • ach_loads_net

  • partner_funds_loads_net

  • marqeta_funds_loads_net

  • direct_deposit_loads_net

  • jit_loads_net (only for JIT Balance columns)

The following columns are considered Spend:

  • sig_purchases_net

  • pin_purchases_net

  • chargebacks

  • currency_conversion_fees

  • program_fees

  • account_funding_transfers

  • original_credit_transfers

Alignment to other reports

The sig_purchases_net field in Balance — Overview/Day equals the sum of sig_purchases + sig_returns in the Card Transactions — Settlements/Clearing Detail report. This field also matches the following in the Amounts Day report:

mastercard_sig_purchases + visanet_sig_purchases + discover_sig_purchases + mastercard_sig_returns + visanet_sig_returns + discover_sig_returns

The pin_purchases_net field in Balance — Overview/Day equals the following sum in the Card Transactions — Settlements/Clearing Detail report:

pin_purchases + pin_returns

This field also matches the following in the Amounts Day report:

maestro_pin_returns + cirrus_pin_returns + interlink_pin_returns + plus_pin_returns + netdebit_pin_returns + pulse_pin_returns + maestro_pin_purchases + cirrus_pin_purchases + interlink_pin_purchases + plus_pin_purchases + netdebit_pin_purchases + pulse_pin_purchases

The jit_loads_net field in Activity Balances/Day equals the sum of Transaction Amount in Loads Detail where Transaction Element is JIT Load, JIT Unload, or JIT Adjustment.

The jit_loads_net in Activity Balances/Day equals the sum of Transaction Amount in Loads Detail where Transaction Element is JIT Load, JIT Unload, or JIT Adjustment.

Pre-clearing data: To track spend that has been authorized, but has not cleared yet, examine the JIT Load fields. The cumulative sum of jit_loads_net provides the pending transaction amount. On any specific day, this value may be positive or negative, depending on whether the net of clearings versus authorizations is positive or negative.

Details

Refresh rate: Full refresh every run (3x a day)
Endpoint: /v2/views/activitybalances/day
Reporting location: Balance > Overview > Day

Acting Cardholder

This report provides a snapshot of a cardholder’s spend vs loads. Based on the day pulled, the report calculates all time until that point. The base table includes information such as activity per day.

Tip
When you retrieve this report in the Dashboard, select Refresh to ensure that complete data has been loaded.
Details

Refresh rate: Full refresh for all cardholders that are flagged with new activity (3x a day).
Endpoint: /v2/views/activitybalances/actor
Reporting location: Balance > Overview > Acting Cardholder

Amount to send
Note
This endpoint is limited in availability. For more information, contact your Marqeta representative.

This report provides a simple view of the amount to send, which is used to move funds between the program funding account and the cardholder account for the prior day’s activity. The report includes both a Program and Sub Program field, which are unique to this report:

  • Program is the same as it is in every other report and maps to a single server instance.

  • Sub Program maps to a program funding account when necessary. In most cases, this is the same value as Program; however, for some programs, there may be a breakout to split the single program to map to the card products that map to each of their program funding accounts.

Details

Refresh rate: Full refresh every run (3x a day)
Endpoint: /v2/views/activitybalances/fundingday
Reporting location: Balance > Overview > Amount To Send

Network Detail

The Network Detail/Day report provides information similar to the Balance — Overview/Day report. The Balance — Overview/Day report is at the day and program level; however; the Activity Balances — Day report provides expanded columns to include network details. For example, instead of providing only the sig_purchases_net column, the Activity Balances — Day report includes a column for every network and subnetwork of sig_purchases_net.

Details

Refresh rate: Full refresh every run (3x a day)
Endpoint: /v2/views/activitybalances/day/networkdetail
Reporting location: Balance > Network Detail > Day

Reserve Balances

The Prefunded — Day/Month report provides a daily or monthly aggregated view of a program’s funding account balance based on a prefunding (on authorization) model. Each day is encompassed by a starting balance, which matches the prior day’s ending balance, and daily activity for funds in and funds out.

  • Funds in come in from deposits.

  • Funds out are aggregated into the amount_to_send field.

  • Amount to Send is the combination of JIT Loads Net and Partner Funds Loads Net.

For detailed information, see JIT Funding Reports.

This report does not represent a program’s entire account balance, but only the program’s funding account balance. For example, a non-JIT program could have a majority of funds in the cardholder account with minimal amount in the program’s funding account.

Details

Refresh rate: Full refresh (3x a day)
Endpoint: /v2/views/programbalances/day & /month
Reporting location: Balance > Reserve Balances > Prefunded — Day & Prefunded — Month

Card transactions

Transactions reporting includes the following types:

  • Authorizations

  • Settlements

  • Declines

  • Loads

  • Network reconciliation

Authorizations

The Authorization (Detail/Day/Week/Month) report provides transaction-level and aggregated views of authorizations activity. These records are added as they occur and are updated when the Transaction Status shifts based on the lifespan of a transaction. For example, an initial transaction is listed with a Transaction Status of Pending Settlement. After a day or more it may be cleared and switch to a status of Successfully Completed. With that event, additional fields such as completion_token are populated.

Not all authorization activity is signature purchase attempts. Activities such as token activation requests are also included.

This report is linked to both the Loads reports and the Clearing report by a token. The transaction_token field in the authorizations report appears as the initiating_transaction_token field in each of those reports.

This report can be joined to the Core API Transaction Token report using the transaction_token field to get the transaction token, listed in webhooks as integer value such as alphanumeric hash. The transaction_token value is the unique value per row, with one row per transaction_token per program. When a transaction changes state, the same row is updated.

Note
PIN activity is considered to be clearing data and is not included in the Authorizations reports.
Authorization reversals

For authorization reversals, there are two useful records in the Authorizations Detail report:

  • transaction_type = authorization & transaction_status = Reversed Authorization (This is the record for the initial authorization)

  • transaction_type = authorization.reversal & transaction_status = Reversal (This is the record for the authorization reversal)

The two records are linked with a common initiating_transaction_token.

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/authorizations/detail (/day, /week, /month)
Reporting location: Transaction > Authorizations > Detail (day, week, month)

Settlements

Settlements reports includes the following types:

  • Clearing Detail

  • Settlements Detail

Clearing Detail

Use the Clearing Detail report for revenue recognition, billing, and funding. This report provides one row for each accounting layer within clearing transaction messages. A single clearing transaction message may be represented as several rows, each corresponding to a different accounting layer. Each event ties to the post_date when the activity was written to the Marqeta ledger.

Key fields
Field Description

transentry_token

The transentry_token field is the unique value per row within the clearing/detail endpoint. This represents each accounting layer within a transaction message. The transaction_token field is the unique value for a transaction message and specifically clearing transaction messages for this endpoint. In many cases, you may encounter several transentry_token entries for every transaction_token—one for the purchase, one for interchange, one for cross border fees, and one for currency conversion fees. These relate to the account_group field.

initiating_transaction_token

Each record has an initiating_transaction_token value, which is related to the corresponding initial authorization record. The corresponding initial authorization record can be found in the Authorizations Detail report by filtering for a transaction_token value that matches the clearing record’s initiating_transaction_token.

post_date

The post_date field is the date that Marqeta processes the transaction. For an authorization, this field indicates when the transaction is authorized and mimics the transaction date. For a clearing record, this field indicates when Marqeta processes the flat files received from the networks and posts it to the Marqeta system. In this case, post_date is the clearing date for those records. In the case of PIN transactions, authorization and clearing occur at the same time, which is the transaction date. Fees occur at a later time for PIN records and mimic the clearing file process.

settlement_date

The settlement_date field is the drawdown date when funds are to be pulled by a network.

sig_purchases

The sig_purchases field includes:

  • sig purchases

  • edge case ATM transactions that come through with a sig network

  • Force Posted AFTs

pin_purchases

The pin_purchases field includes:

  • pin purchases

  • ATM transactions

  • pin reversals (comes through as a positive number in pin_purchases)

core_api_transaction_token

The token of the corresponding transaction from the Core API.

Usage tips

To identify forced captures (Force Posts), filter for:

Transaction Status == Force Post Settlement

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/clearing/detail
Reporting location: Transaction > Settlements > Clearing Detail

Settlements

The Settlements (Detail/Day/Week/Month) report provides a collapsed view of what is in the Clearing/Detail report for investigation and analysis, and not for revenue recognition, billing, or reconciliation. This report allows you to derive useful metrics such as average transaction value.

In this report, the many events that span multiple days are collapsed into a single record to reflect all the clearing impacts associated with a single initiating transaction token, which in most cases are associated with an authorization event. A single authorization can theoretically lead to several events in the clearing detail, such as one or more clearing events and potential fees such as currency conversion fees.

In Settlements/Detail, the rows are collapsed into separate columns. This report is an aggregation of clearing detail information, where each transaction chain (associated with one initiating_transaction_token) is collapsed into a single record. Because transaction chains typically have multiple transaction token values, the transaction_token field identifies the transaction token of the purchase record in the transaction chain. In some cases, there may be a distinct initiating_transaction_token with no associated purchase records. In that case, the value of purchase is -1. Because the initiating_transaction_token values are unique, there should be no record duplicates.

Key fields

The post_date field in this report reflects the minimum post date of a given transaction chain. Use the /views/clearing/detail endpoint or Card Transactions — Settlements > Clearing Detail in the Marqeta Dashboard.

The transaction_status field in Clearing Detail reflects the final state. The possible final states are:

  • Clear Settlement: Signature purchases or return.

  • Successful PIN Transaction: PIN purchase.

  • Forced Post Settlement: Force posted clearing.

  • Cleared Return: Signature or PIN return.

  • Reversal: PIN reversal.

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/settlements/detail (/day, /week, /month)
Reporting location: Transaction > Settlements > Detail (day, week, month)

Declines

The Declines (Detail/Day/Week/Month) report has some overlap with Authorizations in that they both show declined activity (declines detail shows pin also and authorizations doesn’t). However, this one is more expansive for a decline analysis as it will show the reasoning behind why a transaction gets declined and the primary entity as to why it was declined.

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/declines/detail (/day, /week, /month)
Reporting location: Transaction > Declines > Detail (day, week, month)

Loads

The Loads (Detail/Day/Week/Month) report shows cardholder loads, which are funds moved into a cardholder’s account.

The primary source of this activity are funds going from the program funding account into the user’s general purpose account. For most programs this is where JIT Loads, JIT Unloads, Partner Funds Loads, and Partner Funds Unloads are contained. These values all refer back to the balance reports. Some other loads that may show up in this report are ACH Loads and Direct Deposit activity.

To see program transfers, filter for transaction_type = transfer.program in Loads/Detail.

Amount to Send can be calculated from this report by summing the transaction_amount values for records with a transaction_element value in:

  • Partner Funds Load

  • Partner Funds Unload

  • Partner Funds Adjustment

  • JIT Load

  • JIT Unload

  • JIT Adjustment

Direct Deposits typically have three records in the report:

  • Transaction_element =

    • Pending Direct Deposit Debit (or Credit)

    • Direct Deposit Debit (or Credit)

    • Partner Funds Load (or Unload)

These three records can be tied together by a shared initiating_transaction_token. Loads detail only reports balancesheet amount though so all Pending Direct Deposits show $0 instead of the pending amount.

The following activity leads to a cardholder load:

  • account.funding.authorization.clearinggpa.credit

  • account.funding.auth_plus_capturegpa.credit

  • authorization.clearinggpa.credit

  • directdeposit.debitgpa.credit

  • pindebitgpa.credit

  • pindebit.atm.withdrawalgpa.credit

  • pindebit.authorization.clearinggpa.credit

  • pindebit.cashbackgpa.credit

  • pindebit.credit.adjustmentgpa.credit

  • account.funding.authorizationgpa.credit.authorization

  • authorizationgpa.credit.authorization

  • authorization.incrementalgpa.credit.authorization

  • account.funding.authorization.reversalgpa.credit.authorization.reversal

  • authorization.advicegpa.credit.authorization.reversal

  • authorization.reversalgpa.credit.authorization.reversal

  • directdeposit.debit.reversalgpa.credit.reversal

  • pindebit.reversalgpa.credit.reversal

  • directdeposit.creditgpa.debit

  • original.credit.auth_plus_capturegpa.debit

  • pindebit.refundgpa.debit

  • refundgpa.debit

  • directdeposit.credit.reversalgpa.debit.reversal

  • original.credit.auth_plus_capture.reversalgpa.debit.reversal

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/loads/detail (/day, /week, /month)
Reporting location: Transaction > Loads > Detail (day, week, month)

Other transactions

Transactions reporting includes the following types:

  • ACH

  • Bill payments

  • Direct deposit

  • ATM

ACH

ACH reports include:

  • ACH Gateway

  • ACH Pending

  • ACH Verification.

ACH Gateway

The ACH Gateway (Detail) report provides details on ACH gateway activity.

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/achgateways
Reporting location: Transaction > ACH > ACH Gateway Detail

ACH Pending

The ACH Pending (Detail) report provides details on pending ACH gateway activity.

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/achpendings
Reporting location: Transaction > ACH > ACH Pending Detail

ACH Verification

The ACH Verification (Detail) report provides verification details on ACH gateway activity.

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/achverifications
Reporting location: Transaction > ACH > ACH Verification Detail

Bill Payments

The Bill Payments (Detail) report provides transaction-level detail for bill payments.

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/billpayments/detail
Reporting location: Transaction > Bill Payments > Detail

Direct Deposit

The Direct Deposit report shows transaction-level detail for direct deposits.

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/directdeposit/detail
Reporting location: Transaction > Direct Deposits > Detail

ATM

This report includes four types of transactions that are relative to ATM transactions: ATM Withdrawal, Quasi Cash, Manual Cash, and Balance Inquiry. An additional dimension atm_sub_network is added to this report to support the use case of billing ATM transactions that come through ATM sub networks like Allpoint and moneypass under subnetwork such as Pulse.

This report includes both cleared and declined transactions. Cleared transactions use the same logic as amounts_day for cleared ATM Withdrawal, Quasi Cash and Manual Cash, balance Inquiries and declined ATM Withdrawal, Quasi Cash and Manual Cash follow the logic of monthly atm_non_atm report that is heavily used by accounting.

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/atm/detail (/day, /week, /month)
Reporting location: Transaction > ATM > Detail (day, week, month)

Program stats

Program stats reports provide data on the following:

  • Cards

  • Users

  • Card counts

  • User counts

Cards

The Cards report provides a Detail view and Card Counts — Day/Week/Month views.

Detail

The Cards/Detail report shows card details, with a single row per card. The report provides a status table as cards transition states, with flags for previous states and the current state of each card.

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/cards/detail
Reporting location: Program Stats > Cards> Detail

Card Counts

The Card Counts — Day/Week/Month report provides aggregate data for cards at the day, week, and month level. The report shows, for example, how many cards are issued, activated, and transacting in each timeframe.

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/cardcounts/day
Reporting location: Program Stats > Card Counts > Day (Week, Month)

Users

The Users report provides a Detail view and User Counts — Day/Week/Month views.

Detail

The Users — Detail report shows user details, with a single row per user. The report provides a status table as users transition states, with flags for previous states and the current state of each user.

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/users/detail
Reporting location: Program Stats > Users > Detail

User Counts

The User Counts — Day/Week/Month report provides aggregate data on users at the day, week, and month level. This shows, for example, how many users are created, active, and transacting in each timeframe.

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/usercounts/day
Reporting location: Program Stats > User Counts > Day (Week, Month)

Risk monitoring

Risk management includes the Chargebacks/Status and Chargebacks/Detail reports for monitoring dispute activity.

The Chargebacks/Status report shows a single row per chargeback including the current status of the chargeback. This report provides useful fields that are not included in the Chargebacks/Detail report and can be also useful for joining with data from other sources.

The Chargebacks/Detail report includes a single row for all the events associated with a chargeback. The chargeback_transition_token field combined with chargeback_token is a unique row in the detail report. These each align to a chargeback_state value. This table includes events that are not disputes in nature, but become associated with them as disputes are established such as the Initial Presentment.

The initiating_transaction_token field in the Chargebacks/Detail report corresponds to the transaction_token field, which is the purchase transaction, in the Clearing/Detail report.

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/chargebacks/status & /detail+ Reporting location: Risk Monitoring > Chargebacks > Status & Detail

System

System reports provide information about your system performance.

The Platform Response/Month report provides a monthly average duration and a gateway duration for transactions based on the best available data.

Details

Refresh rate: Once a month refresh
Endpoint: /v2/views/platformresponse/month
Reporting location: Program Stats > Platform Response > Month

Utilities

Utility reports provide information that supports the Marqeta reporting features. These reports include the following utility reports:

  • Core API Transaction Token

  • Data Dictionary

Core API Transaction Token

The Core API Transaction Token report is a pure lookup between the Core API transaction token and the transaction token as listed in many reports. Because the transaction token set in the Core API often is not the same transaction token as in the report, you can join this table as a lookup to match to your internal data logs.

The core_api_tranaction_token and core_api_initiating_transaction_token fields are available in several endpoints. For these reports, a lookup to this report is not required.

Details

Refresh rate: Incremental refresh (3x a day)
Endpoint: /v2/views/transactiontoken
Reporting location: Transaction > Core API Transaction Token

Data Dictionary

The Data Dictionary provides information on the data dictionary, which describes the data for each of the columns in reports.

Details

Refresh rate: Full Refresh (Once a Day)
Endpoint: /v2/views/datadictionary
Reporting location: Utilities > Data Dictionary

Feedback on this page?

If you feel we can do anything better, please let our team know.