Skip to main content

Introduction

Nium helps you simplify your cross-border payments with Global Collection Accounts. You can receive payments from your payers in their local currency. Nium currently supports USD, EUR, GBP, SGD, AUD, HKD, and INR as collection currencies.

Glossary of terms:

Partner - Partner is an entity who contracts with Nium and brings their client/business to Nium.

Client - Client is an entity who has business need to move funds. As per regulation we need to do KYB for client. A partner can have multiple clients.

Currency Account/Wallet - Virtual account on nium platform where money can be parked. Each Currency account has unique number and currency. A client can have multiple currency accounts.

Virtual Receiving Account (VRA) - This is a real virtual account which Nium generated with the help of Partner bank and this account is tied to client. Any funds coming to this account moves directly to currency account/wallet.

Payer - Payer is the entity whom clients wants to invoice and wants to collect funds from.

Payment Request - This is a request which Client sends to Payer with invoice details for collecting funds.

PER_CURRENCY Approach - In this approach client only expects one VRA per currency and all the payer pays to same VRA. Client carries the individual reconciliation by itself.

PER_PAYER Approach - In this approach client creates individual VRA at payer level. So, when payment arrives there is a clear segregation of which payer paid the fund

Sender - The entity who pays the money to Virtual receiving account. In real world, it should be same as Payer.

Remitter - Remitter is the entity who wants to move fund. He can be client directly or customer of client.

Beneficiary - Person to whom funds needs to be transferred. Beneficiary will have bank account associated with him where remitter will send fund to.

BookFX - Moving money from one currency account to another currency account within same client at a spot exchange rate is called as BookFX.

RFI - Request for more information. This is required when a transaction gets flagged in compliance check and compliance team needs further input on the transaction from client for approving the transaction.

Masspay - UI portal which facilitates the entire payout journey.

Use case flow (PER_CURRENCY):

Journey starts with Partner or Client signing contract with Nium to collect money from payer and withdraw money to their self account.

Partner is totally an optional concept. In few use cases we can have partner who brings client to Nium or in some cases client directly interacts with Nium.

Step 1 - Nium performs KYB for client. Current process is manual for KYB. Client is setup in PER_CURRENCY approach.

Step 2 - Nium creates currency account for Client.

Step 3 - Client calls the API “Add Bank Account” to seed the withdrawal bank account where clients wants to withdraw the money which he has collected.

Step 4 - Client calls API “Allocate virtual Receiving account” or uses UI to allocate virtual receiving account(VRA). In case of EUR, GBP and AUD process is asynchronous and client will be notified for VRA allocation via webhook “Virtual Receiving Account Status Update”. Rest of the currency is real time allocation.

Step 5 - Create a payer using API “Add Payer”. This will respond with PayerId and VRA details.

Step 6 - Create a payment Request by supplying invoice details using API “Create Payment Request”. Payer is notified over email with payment request and VRA where he has to pay the money.

Step 7 - Payer/Sender pays the money to VRA account by quoting Payment request number in Narrative. In real time, we receive the nudge from our partner bank. Client can subscribe using webhook “Fund Arrival and Status change” to know fund arrival in real time. We run AML screening on Payer/Sender to identify any potential AML issue. If AML check is clean, we post the money to currency account.

Step 8a - As per regulation, for few corridors we will autosweep and transfer the money to account added in step 3.

Step 8b - Client can self withdraw the money by calling the API “Withdraw Fund

Step 8c - In case AML is not clean and compliance officer raises a RFI. Client will be notified via webhook “Fund Arrival and Status change” for status change. Client is expected to call API “Get virtual receiving account statement” to know the current status of transaction. If the sub-status is RFI-RAISED. Clients needs to call API “GET ALL RFI” by providing transactionId to find the reason for RFI. Subsequently, client needs to call API “Submit RFI Response” for a given rfiId by supplying data/document and transaction will move to RESPONDED status. Once compliance officer approves the transaction, money gets credited to wallet.

Use case flow (PER_PAYER):

Journey starts with Partner or Client signing contract with Nium to collect money from payer and withdraw money to their self account.

Partner is totally an optional concept. In few use cases we can have partner who brings client to Nium or in some cases client directly interacts with Nium.

Step 1 - Nium performs KYB for client. Current process is manual for KYB. Client is setup in PER_PAYER approach.

Step 2 - Nium creates currency account for Client.

Step 3 - Client calls the API “Add Bank Account” to seed the withdrawal bank account where clients wants to withdraw the money which he has collected.

Step 4 - Client calls create payer using API “Add Payer”. This will respond with PayerId and VRA details. Client can create n number of Payers and for each payer individual Virtual Receiving Account(VRA) will be allotted.

Step 5 - Client creates a payment Request for a payer by supplying invoice details using API “Create Payment Request”. Payer is notified over email with payment request and VRA where he has to pay the money.

Step 6 - Payer/Sender pays the money to VRA account by quoting Payment request number in Narrative. In real time, we receive the nudge from our partner bank. We run AML screening on Payer/Sender to identify any potential AML issue. If AML check is clean, we post the money to currency account.

Step 7a - As per regulation, for few corridors we will autosweep and transfer the money to account added in step 3.

Step 7b - Client can self withdraw the money by calling the API “Withdraw Fund

Step 7c - In case AML is not clean and compliance officer raises a RFI. Client will be notified via webhook “Fund Arrival and Status change” for status change. Client is expected to call API “Get virtual receiving account statement” to know the current status of transaction. If the sub-status is RFI-RAISED. Clients needs to call API “GET ALL RFI” by providing transactionId to find the reason for RFI. Subsequently, client needs to call API “Submit RFI Response” for a given rfiId by supplying data/document and transaction will move to RESPONDED status. Once compliance officer approves the transaction, money gets credited to wallet.