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 20213.74Updated formatting to match brand guidelines
2nd June 20213.76Introduced tab in Scheduled Loads Report to list all pending loads
13th August 20213.79Added ECB rate definition to Card Activity daily and monthly reports
24th August 20213.79Revised Card Activity Custom Field definition
12th April 20223.79Product and documentation rebranding
29th November 20213.83Added disputes to the Balance Sheet Report.
Added dispute transaction types to the Card activity: Daily report.
19th of August 20223.91Redirect hosting URLs from Ixaris into Nium domain
12th of January3.91Product documentation transition to web view

Available reports

Card activity: DailyThis report contains all the transactions made on a specific day on all cards.
Card activity: MonthlyThis report contains all the transactions made in a specific month on all cards.
Funding account activity: DailyThis report contains all the transactions for each funding account for a specific day.
Funding account activity: MonthlyThis report contains all the transactions for each funding account for a specific month.
Non-zero card balancesThis report contains all the cards with an actual balance greater than zero.
Balance sheetThis report contains a breakdown of the sum of funds deposited and how the funds have been used.
Scheduled loadsThis report contains current pending loads and the minimum amount required in a funding account (per currency) to cover all the pending loads.
Credit activityThis report contains a daily snapshot at the end of the day, visualizing all the credit activity for a deployment's credit funding accounts.
Credit statementA 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
FREQUENCYDESCRIPTION
DailyA daily report contains a list of transactions made on a specific day.
MonthlyA 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:

  1. Collects data from suppliers for the previous day.
  2. Stores collected data in a data repository.
  3. Validates stored data to check if it is correct and complete.
  4. Inserts transactions or files that failed validation into an audit table.
  5. Generates reports only for accurate and complete data.
  6. 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:

  1. Take Β£50 from funding account A
  2. 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