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.

🚧

IMPORTANT

This document is intended solely for the recipient and only for use for the purposes agreed by Nium with the recipient. It contains confidential and commercially sensitive information. Do not use, copy or disclose the information contained in this document. If you have received this document in error, or if you are not bound by a confidentiality agreement with Nium, please notify us and immediately on [email protected] and delete or destroy the document and all copies you may have.

📘

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?

Available reports

Report naming conventions

Nium reports following these naming conventions.

Daily report convention:

Monthly report convention:

This is how to interpret report elements:

📘

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).

The following are example report names with an explanation of their structure:

Card_Activity_daily_2017-06-25-05-31-21_0000001

Funding_Account_Activity_monthly_2017-06-03-05-34-55_2017-05

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