Reports Reference
Product version 3.91
Last edited January 2023
About this guide
Overview
The Nium product comes with a set of reports. These reports are used to reconcile financial activities performed through the application. This reference guide will show you how to access, interpret and use standard Nium reports.
NOTE
You can access full transaction history of a card using the Nium API, but this type of access is generally not feasible. You can use reports instead.
What’s new in this version?
15th February 2021 | 3.74 | Updated formatting to match brand guidelines |
2nd June 2021 | 3.76 | Introduced tab in Scheduled Loads Report to list all pending loads |
13th August 2021 | 3.79 | Added ECB rate definition to Card Activity daily and monthly reports |
24th August 2021 | 3.79 | Revised Card Activity Custom Field definition |
12th April 2022 | 3.79 | Product and documentation rebranding |
29th November 2021 | 3.83 | Added disputes to the Balance Sheet Report. Added dispute transaction types to the Card activity: Daily report. |
19th of August 2022 | 3.91 | Redirect hosting URLs from Ixaris into Nium domain |
12th of January | 3.91 | Product documentation transition to web view |
Available reports
Card activity: Daily | This report contains all the transactions made on a specific day on all cards. |
Card activity: Monthly | This report contains all the transactions made in a specific month on all cards. |
Funding account activity: Daily | This report contains all the transactions for each funding account for a specific day. |
Funding account activity: Monthly | This report contains all the transactions for each funding account for a specific month. |
Non-zero card balances | This report contains all the cards with an actual balance greater than zero. |
Balance sheet | This report contains a breakdown of the sum of funds deposited and how the funds have been used. |
Scheduled loads | This report contains current pending loads and the minimum amount required in a funding account (per currency) to cover all the pending loads. |
Credit activity | This report contains a daily snapshot at the end of the day, visualizing all the credit activity for a deployment's credit funding accounts. |
Credit statement | A credit statement issued per deployment outlining the final outstanding balance per funding account as of the cycle end date. |
Report naming conventions
Nium reports following these naming conventions.
Daily report convention:
All daily report names follow the following naming convention: |
---|
reportName_frequency_reportGenerationDate_batchNumber |
Monthly report convention:
All monthly report names follow the following naming convention: |
---|
reportName_frequency_reportGenerationDate_transactionMonth |
This is how to interpret report elements:
ELEMENT |
---|
reportName |
This element indicates the name of the report, for example: Card_Acvitity, Funding_Account_Activity |
frequency |
This element indicates the report frequency and can have one of two values: Daily \ or \ Monthly |
FREQUENCY | DESCRIPTION |
---|---|
Daily | A daily report contains a list of transactions made on a specific day. |
Monthly | A monthly report contains data for a specific calendar month from the first day to the last day of the calendar month. |
reportGenerationDate |
This element indicates the date and time when the system generated the report. The date is presented in the following format:yyyy-mm-dd-hh24-mi-ss |
NOTE
All time values are represented using the Coordinated Universal Time (UTC). UTC does not change with local time (not affected by daylight saving time).
batchNumber |
This element is used only in daily reports. It is a unique batch number associated with each report. The batch number is generated within a specific deployment and/or community. |
transactionMonth |
This element is used only in monthly reports. It is the month of the set of transactions listed in the report. The month is presented in the following format: yyyy-mm |
The following are example report names with an explanation of their structure:
Card_Activity_daily_2017-06-25-05-31-21_0000001
report_Name = | Card_Activity |
frequency = | Daily |
reportGenerationDate = | 2017-06-25-04-31-21 June 25, 2017 at 04:31:21 hrs |
batchNumber = | 0000001 The first report file generated for this deployment or community |
Funding_Account_Activity_monthly_2017-06-03-05-34-55_2017-05
reportName = | Funding_Account_Activity |
frequency = | Monthly |
ReportGenerationDate = | 2017-06-03-05-34-55 June 3, 2017 at 05:34:55 hrs |
transactionMonth = | 2017-05 Contains data for transactions from 1 to 31 May 2017 |
Report creation process
Nium reports are created daily and stored in the file repository.
The Nium report generation engine performs the following process every day:
- Collects data from suppliers for the previous day.
- Stores collected data in a data repository.
- Validates stored data to check if it is correct and complete.
- Inserts transactions or files that failed validation into an audit table.
- Generates reports only for accurate and complete data.
- Stores generated reports in files in the file repository.
NOTE
If there is no activity on the reporting account for more than two months, the engine stops generating reports.
If there are any transactions or files that failed validation, the business intelligence team performs the following manual process:
- Analyses the audit table.
- Eliminates issues with data in the audit table.
- Manually generates a report.
- Stores the report in a file in the file repository with the next batch number
NOTE
Monthly reports do not need to be corrected because they are based on complete daily reports.
File repository
The file repository contains report files. Each deployment has a dedicated folder in the repository.
IMPORTANT
To access the file repository, use the link that you received by email. If you have not received the link by email, contact your IT team for help.
This is the general structure of the file repository:
Deployment folder
You have access to your dedicated deployment folder. This folder contains subfolders for each type of report. Your deployment folder is structured like this:
A report can have different frequencies (daily or monthly). The available frequencies are represented as subfolders for that report. The Daily subfolder contains reports scheduled for daily generation, and likewise, the Monthly subfolder contains reports generated monthly (transactions from the previous month). Your report folder is structured like this:
Reporting on suspended transactions
Sometimes, a transaction is reported as in a suspended state. In these cases, Nium does not have access to any information about the status of the operation upon request from an external provider (e.g., a card processor).
For example, consider requesting £50 to be transferred from a funding account to a virtual card. This will include the following steps:
- Take £50 from funding account A
- Put £50 on virtual card B
For funds to be placed on the virtual card (step 2), a card processor must perform an external operation on Nium. In this example, an exception may occur if Nium has no access to the status of the request sent to the card processor (perhaps due to a communication problem). If so, Nium has no information about whether the funds have been loaded on the card. In this example, Nium will mark the transaction as suspended until a Nium officer investigates the outcome of the operation. If the operation is successful, the fund movement is marked as completed. If the operation fails, the withdrawal of funds from the funding account (step 1) is reversed.
A partial transaction report is created for such transactions (fund movement that has already occurred is reported). In the above example, the Funding Account Activity report would show the movement of funds from the funding account. The transaction status will be INITIALISED, which indicates that this transaction is suspended and not yet completed.
In case of failure, funds will be reversed, and the transaction status will be INITIALISED_FAILED. In case of successful completion, the transaction will be continued and marked as INITIALISED_COMPLETED.
A transactionId is a unique reference for each transaction. It can reconcile the entries in Funding Account Activity and Card Activity reports for a particular transaction. For every INITIALISED transaction, there must be a corresponding entry with the same transactionId and with an INITIALISED_FAILED or an INITIALISED_COMPLETED status. If not, the underlying issue probably still applies, or an error has occurred.
Please report any transactions (INITIALISED) that do not have a corresponding completion state (INITIALISED_FAILED or INITIALISED_COMPLETED) to the Nium support team on [email protected].
Reports
All activities you perform in Nium can be tracked using reports. In this section, we provide the full specification for the following reports:
- Card activity: Daily
- Card activity: Monthly
- Funding account activity: Daily
- Funding account activity: Monthly
- Non-zero card balances
- Balance sheet
- Scheduled loads
- Credit activity: Daily
- Credit statement: Daily
Updated 12 months ago