> ## Documentation Index
> Fetch the complete documentation index at: https://www.marqeta.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Reports In-depth
> Detailed information on Marqeta reports.
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 monitoring
* System
* Utilities
* RiskControl Real-Time Decisioning
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:45 PM UTC | 8:45 PM UTC |
| Afternoon | Mid-day run that includes all data since prior data run. | 3:45 AM UTC | 7:45 AM UTC |
| Overnight (Prior Data Run) | Prior day UTC data. | 8:45 AM UTC | 1:00 PM UTC |
The 3:45 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
* 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.
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`
The `jit_loads_net` field in **Balance - Overview/Day** equals `transaction_amount` in the **Card Transactions - Loads/Detail** report 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**
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 **Balance - 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 **Balance - Network Detail/Day** report provides expanded columns to include network details. For example, instead of providing only the `sig_purchases_net` column, the **Balance - Network Detail/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**
Program Funding Balances
The **Balance - Program Funding Balances/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](/developer-guides/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 - Program Funding Balances/Prefunded - Day** & **Prefunded - Month**
Card transactions
Transactions reporting includes the following types:
* Authorizations
* Settlements
* Declines
* Loads
* Network reconciliation
Authorizations
The **Card Transactions - Authorizations (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 **Card Transactions - 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**: **Card Transactions - Authorizations/Detail (Day, Week, Month)**
Settlements
Settlements reports includes the following types:
* Clearing Detail
* Settlements Detail
Clearing Detail
Use the **Card Transactions - Settlements/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 **Card Transactions - 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**: **Card Transactions - Settlements/Clearing Detail**
Settlements Detail
The **Card Transactions - Settlements/Settlements Detail** report provides a collapsed view of what is in the **Card Transactions - Settlements/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 **Card Transactions - Settlements/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.
The `transaction token` field represents the purchase transaction token. In cases where both purchases and returns equal 0, the `transaction_token` value is -1.
Key fields
The `post_date` field in this report reflects the minimum post date of a given transaction chain.
The `transaction_status` field 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**: **Card Transactions - Settlements/Settlements Detail/Day/Week/Month**
Declines
The **Card Transactions - 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**: **Card Transactions - Declines/Detail/Day/Week/Month**
Loads
The **Card Transactions - 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.clearing` ⇒ `gpa.credit`
* `account.funding.auth_plus_capture` ⇒ `gpa.credit`
* `authorization.clearing` ⇒ `gpa.credit`
* `directdeposit.debit` ⇒ `gpa.credit`
* `pindebit` ⇒ `gpa.credit`
* `pindebit.atm.withdrawal` ⇒ `gpa.credit`
* `pindebit.authorization.clearing` ⇒ `gpa.credit`
* `pindebit.cashback` ⇒ `gpa.credit`
* `pindebit.credit.adjustment` ⇒ `gpa.credit`
* `account.funding.authorization` ⇒ `gpa.credit.authorization`
* `authorization` ⇒ `gpa.credit.authorization`
* `authorization.incremental` ⇒ `gpa.credit.authorization`
* `account.funding.authorization.reversal` ⇒ `gpa.credit.authorization.reversal`
* `authorization.advice` ⇒ `gpa.credit.authorization.reversal`
* `authorization.reversal` ⇒ `gpa.credit.authorization.reversal`
* `directdeposit.debit.reversal` ⇒ `gpa.credit.reversal`
* `pindebit.reversal` ⇒ `gpa.credit.reversal`
* `directdeposit.credit` ⇒ `gpa.debit`
* `original.credit.auth_plus_capture` ⇒ `gpa.debit`
* `pindebit.refund` ⇒ `gpa.debit`
* `refund` ⇒ `gpa.debit`
* `directdeposit.credit.reversal` ⇒ `gpa.debit.reversal`
* `original.credit.auth_plus_capture.reversal` ⇒ `gpa.debit.reversal`
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/loads/detail (/day, /week, /month)`\
**Reporting location**: **Card Transactions - 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 Origination
ACH Gateway
The **Other Transactions - ACH/ACH Gateway Detail** report provides details on ACH gateway activity.
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/achgateways`\
**Reporting location**: **Other Transactions - ACH/ACH Gateway Detail**
ACH Pending
The **Other Transactions - ACH/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**: **Other Transactions - ACH/ACH Pending Detail**
ACH Verification
The **Other Transactions - ACH/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**: **Other Transactions - ACH/ACH Verification Detail**
ACH Origination
The **Other Transactions - ACH Origination/ACH Origination Detail** report shows transaction-level detail for ACH Origination transfers, for both Program Funding and User Funding use cases.
**Note**\
An ACH origination transaction with a NULL `transaction_token` value indicates that the transaction either contains an error or was canceled before funds were moved.
Program Account Funding use case
Programs enabled for ACH origination can move funds between their program funding accounts and external program funding sources. A program can pass a `funding_source` token representing the external account via the `banktransfers/ach` endpoint, and funds are pushed to or pulled from that external account.
User Account Funding use case
Programs enabled for ACH origination can move funds between a cardholder GPA and an external cardholder ACH funding source. Customers can pass a `funding_source` token representing the external account via the `banktransfers/ach` endpoint, and funds are pushed to or pulled from the external account.
Details
**Refresh rate**: Full refresh (3x a day)\
**Endpoint**: `/v2/views/achorigination/detail`\
**Reporting location**: **Other Transactions - ACH Origination/ACH Origination Detail**
Bill Payments
The **Other Transactions - 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**: **Other Transactions - Bill Payments/Detail**
Direct Deposit
The **Other Transactions - Direct Deposit/Detail** report shows transaction-level detail for direct deposits.
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/directdeposit/detail`\
**Reporting location**: **Other Transactions - Direct Deposit/Detail**
ATM
The **Other Transactions - ATM/Detail/Day/Week/Month** report includes four types of transactions relative to ATM transactions: ATM Withdrawal, Quasi Cash, Manual Cash, and Balance Inquiry. The `atm_sub_network` field supports billing ATM transactions that come through ATM sub networks.
This report includes both cleared and declined transactions. Cleared transactions use the same logic as `amounts_day` for cleared ATM withdrawal, quasi cash, manual cash, and balance inquiries. Declined ATM withdrawal, quasi cash, and manual cash follow the logic of a 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**: **Other Transactions - ATM/Detail/Day/Week/Month**
Credit
Credit reports provide data on the following:
* Account Adjustments
* Account Adjustments Monthly
* Account Details
* Account Daily Balances
* Account Cards
* Disputes
* Disputes Monthly
* Journal Entries
* Payments
* Rewards
* Rewards Monthly
* Statements
Account Adjustments
The **Credit - Account Adjustments** report provides details on adjustments made to the credit accounts in a program, including the adjusted amount, reason, and date the adjustment was made. Key fields include `original_ledger_entry_token`, `external_adjustment_id`, and `adjustment_detail_token`.
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/credit/accountadjustments/detail`\
**Reporting location**: **Credit - Account Adjustments**
Account Adjustments Monthly
The **Credit - Account Adjustments Monthly** report provides adjustments data for all the credit accounts for a month in a program. Key fields are `account_token`, `total_amount`, and `month_key`.
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/credit/accountadjustments/month`\
**Reporting location**: **Credit - Account Adjustments Monthly**
Account Details
The **Credit - Account Details** report provides details on all of the credit accounts in a program. This report includes intra-monthly balance calculations attached to each account, including purchases, interest, fees, credits, and payments, which are updated whenever an activity occurs that might affect the ledger. Key fields are `current_balance`, `available_credit`, and `credit_limit`.
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/credit/accounts/detail`\
**Reporting location**: **Credit - Account Details**
Account Daily Balances
The **Credit - Account Daily Balances** report provides details on daily balances, including principal, interest, fees, and payment allocations.
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/credit/accountdailybalances/detail`\
**Reporting location**: **Credit - Account Daily Balances**
Account Cards
The **Credit - Account Cards** report provides detailed information for the cards in a program, such as the current card state, product, and creation and end dates.
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/credit/cards/detail`\
**Reporting location**: **Credit - Account Cards**
Disputes
The **Credit - Disputes** report provides dispute details of all dispute activity for the credit accounts in a program.
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/credit/disputes/detail`\
**Reporting location**: **Credit - Disputes**
Disputes Monthly
The **Credit - Disputes Monthly** report provides dispute data by month for all credit accounts in a program. This report provides an aggregated sum of all disputes grouped by account and status (`WON`, `LOST`, or `REVERSED`). Active disputes are skipped. For example, if an account has three disputes, with two won and one lost, two records are returned—one record with the sum of all disputes won, and the other with the sum of all disputes lost.
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/credit/disputes/month`\
**Reporting location**: **Credit - Disputes Monthly**
Journal Entries
The **Credit - Journal Entries** report provides details of all ledger entries for all credit accounts in a program, such as the status and amount.
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/credit/journalentries/detail`\
**Reporting location**: **Credit - Journal Entries**
Payments
The **Credit - Payments** report provides payment details for all the credit accounts in a program, such as payment method, interest, and fees.
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/credit/payments/detail`\
**Reporting location**: **Credit - Payments**
Rewards
The **Credit - Rewards** report provides a rewards detail for all the credit accounts in a program.
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/credit/rewards/detail`\
**Reporting location**: **Credit - Rewards**
Rewards Monthly
The **Credit - Rewards Monthly** report provides a sum of all credit account rewards for a given month grouped by account token.
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/credit/rewards/month`\
**Reporting location**: **Credit - Rewards Monthly**
Statements
The **Credit - Statements** report provides a statements summary for credit accounts. This report is an amalgamation of Credit’s Statement Summary, Statement Payment Info, and Statement Year-to-date. Each entry in this report encapsulates the data that is associated with an account for these three statements. Key fields include `opening_balance`, `closing_balance`, `available_credit`, and `past_due_amount`.
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/credit/statements/current`\
**Reporting location**: **Credit - Statements**
Program stats
Program stats reports provide data on the following:
* Cards
* Users
* Card counts
* User counts
Cards
The **Program Stats - Cards** reports provides a **Detail** view and **Card Counts - Day/Week/Month** views.
Detail
The **Program Stats - 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 **Program Stats - Cards/Card Counts - Day/Card Counts - Week/Card Counts - Month** report provides aggregate data for cards at the day, week, and month level. The report shows card count data such as 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 - Cards/Card Counts - Day/Card Counts - Week/Card Counts - Month**
Users
The **Program Stats - Users** report provides a **Detail** view and **User Counts - Day/Week/Month** views.
Detail
The **Program Stats - 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 **Program Stats - User/User Counts - Day/User Counts - Week/User Counts - Month** report provides aggregate data on users at the day, week, and month level. This shows user count data such as 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/User Counts - Day/User Counts - Week/User Counts - Month**
Risk monitoring
Risk management includes the **Risk Monitoring - Chargebacks/Status** and **Risk Monitoring - Chargebacks/Detail** reports for monitoring dispute activity.
The **Risk Monitoring - 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 **Risk Monitoring - Chargebacks/Detail** report and can be also useful for joining with data from other sources.
The **Risk Monitoring - 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 **Card Transactions - Settlements/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 **System - 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**: **System - 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 **Utilities - Core API Transaction Token/Lookup** 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**: **Utilities - Core API Transaction Token/Lookup**
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/Data Dictionary**
RiskControl Real-Time Decisioning
RiskControl Real-Time Decisioning reporting includes the following types:
* Authorizations
* Transaction Count by Rules
Authorizations
The **RiskControl Real-Time Decisioning - Authorizations** report provides information on all the transaction authorizations processed by Real-Time Decisioning, including Transaction Token, Acting User Token, User Token, Card Token, Amount, Risk Score, Risk Level, Recommended Action, Rule Violation, and Tags.
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/cpauth/detail/`\
**Reporting location**: **RiskControl Real-Time Decisioning - Authorizations**
Transaction Count by Rules
The **RiskControl Real-Time Decisioning - Transaction Count by Rules** report provides information on the count of transactions per triggered rule for a program.
Details
**Refresh rate**: Incremental refresh (3x a day)\
**Endpoint**: `/v2/views/cptrxn/rule/detail/`\
**Reporting location**: **RiskControl Real-Time Decisioining - Transaction Count by Rules**
## Related topics
- [Reports in the Marqeta Dashboard](/docs/developer-guides/reports-dashboard.md)
- [2022 Release Notes](/docs/developer-guides/release-notes-2022.md)
- [ACH Origination](/docs/diva-api/ach-origination.md)
- [Settlements](/docs/diva-api/settlements.md)
- [2021 Release Notes](/docs/developer-guides/release-notes-2021.md)