Recognizing Payments

When your business sends payouts through Nium, recipients expect two things:

1. To know who sent the money.
2. To understand what the payment is for.

If recipients cannot identify payments on their bank statements, it causes confusion and delays reconciliation.

Bank statements vary across countries and payment methods. Some corridors show both the sender’s name and your reference text. Others restrict what appears, and some display only system-generated reference numbers.

This guide explains how Nium keeps payments identifiable, how visibility differs by corridor, and how to configure payouts for a better customer experience.

How Nium ensures visibility

Bank statements vary widely by country and clearing system. To maximize visibility, Nium applies the following to every transaction:

1. Custom sender name delivered (when corridors permit): Nium passes your customer’s name as the sender (remitter.name). The recipient sees the ultimate sender.
2. Fixed sender name (add reference text): If the corridor enforces a fixed sender name (e.g., “NIUM Fintech” or “INSTAREM”), Nium forwards your customerComments such as customer name and invoice/order ID.
   • If you don’t provide customerComments, Nium auto-populates with Remitter Name + Nium Transaction ID.
3. References only (clearing system identifiers): In corridors that don’t display custom sender names or comments, recipients identify payments using system generated clearing references including Unique transaction references (UTR), bank reference number, transaction reference number, or Nium transaction ID.

Your recipient will always see some identifying details to recognize or trace the payment.

Because bank statement formats vary, Nium applies these rules to maximize visibility:

1. Sender name supported: Nium passes your customer’s name in remitter.name.
2. Fixed sender name: When the corridor enforces a fixed sender name (for example, NIUM Fintech or INSTAREM):
   • If the corridor enforces a fixed sender name (e.g., “NIUM Fintech” or “INSTAREM”), Nium returns your customerComments including customer name and invoice/order ID.
   • If you don’t provide customerComments, Nium auto-populates the field with <Remitter Name> and Nium Transaction ID.
3. References only: In corridors that don’t allow custom names or comments, recipients identify payments using transaction reference data, including:
   • Unique transaction reference (UTR)
   • Bank reference number
   • Nium Transaction ID

Corridor categories

Corridors generally fall into three categories:

Sender name and reference both shown

• Example: EUR, AUD, SGD
• Bank statement:

CREDIT: ABC Ltd
REF: Invoice 1234

Fixed sender name — reference text shown

• Example: GBP, HKD, MYR
• Bank statement:

CREDIT: NIUM FINTECH
REF: ABC Ltd / Invoice 1234

Reference only (clearing IDs)

• Example: INR, VND, MXN
• Bank statement:

CREDIT: ABC Corp
REF: UTR 20250928012345

Configuring payouts

When creating a payout, you configure two fields:

Field	Purpose	Notes
remitter.name	Sends your customer’s name as the sender.	Some corridors override the remitter.name with fixed names (e.g., GBP, HKD, MYR).
customerComments	Free field to include reference details (customer name, invoice ID, order ID).	Length and characters vary. May be shortened or removed by banks.

Think of these as the Sender Name and Payment Reference.

Corridor visibility

Currency	Country	Customer Name as Remitter	Remitter Name Visibility	Narrative / Comments Visibility	Other Information
AUD	Australia	Yes	Visible	Visible
EUR	European Union	Yes	Visible	Visible
SGD	Singapore	Yes	Visible	Not visible	Transaction Reference Number
JPY	Japan	Yes	Visible	Not visible
KRW	South Korea	Yes	Visible	Not visible
NPR	Nepal	Yes	Visible	Not visible	Bank Transaction Reference Number
GBP	United Kingdom	No (fixed as NIUM Fintech)	Fixed as NIUM Fintech	Visible
MYR	Malaysia	No (fixed as NIUM SDN. BHD.)	Fixed as NIUM SDN. BHD. (FKA Instarem)	Visible
BDT	Bangladesh	Limited (clearing restrictions)	Limited by clearing system	Not visible
BRL	Brazil	Limited (proxy only)	Proxy transactions only	Not visible
CAD	Canada	Bank dependent	Sent to recipient’s bank	Sent to recipient’s bank
COP	Colombia	Limited (clearing restrictions)	Limited by clearing system	Not visible
HKD	Hong Kong	No (fixed as INSTAREM)	Fixed as INSTAREM	Sent to recipient’s bank	Transaction Reference Number
IDR	Indonesia	Limited (clearing restrictions)	Limited by clearing system	Not visible	Transaction Reference Number
INR	India	Limited (proxy only)	Proxy transactions only	Not visible	Bank Reference Number
LKR	Sri Lanka	Limited (clearing restrictions)	Limited by clearing system	Not visible
MXN	Mexico	Limited (clearing restrictions)	Limited by clearing system	Not visible
PHP	Philippines	Bank dependent	Sent to recipient’s bank	Sent to recipient’s bank
PKR	Pakistan	Bank dependent	Sent to recipient’s bank	Not visible
PLN	Poland	Bank dependent	Sent to recipient’s bank	Sent to recipient’s bank	Transaction Reference Number
THB	Thailand	Limited (clearing restrictions)	Limited by clearing system	Not visible
TRY	Turkey	Bank dependent	Sent to recipient’s bank	Not visible
USD	United States	Bank dependent	Sent to recipient’s bank	Sent to recipient’s bank	Nium Transaction ID
VND	Vietnam	Limited (clearing restrictions)	Limited by clearing system	Not visible	Bank Transaction Reference Number

Legend

• Yes: Customer’s name can be sent directly as the remitter.
• Limited: Supported only in restricted cases (proxy, clearing limits, or dependent on beneficiary bank). Refer to playbook for more details.
• No: Corridor enforces a fixed remitter (e.g., NIUM / Instarem).

Example scenarios

Sender name shown (EUR)

"remitter": { "name": "John Smith" },
"customerComments": "Invoice #1234"

Bank Statement

CREDIT: JOHN SMITH
REF: Invoice #1234

Fixed sender name, comments displayed (GBP)

"remitter": { "name": "John Smith" },
"customerComments": "Invoice #1234"

Bank Statement

CREDIT: NIUM FINTECH
REF: John Smith / Invoice #1234

Fixed sender name, no comments (GBP)

"remitter": { "name": "John Smith" }

Bank Statement

CREDIT: NIUM FINTECH
REF: John Smith - Nium Txn 987654321

References only (INR)

"remitter": { "name": "John Smith" }

Bank Statement

CREDIT: ABC CORP
REF: UTR 20250928012345

Identifying payments

Recipients rely on a combination of:

• Sender Name: when allowed by the corridor.
• Reference Text: custom comments you provide.
• System Identifiers: UTRs, bank reference numbers, or Nium Transaction IDs.

Best experience: Sender name and Reference text. Fallback: Reference text or System identifiers.

Best practices

• Always include your customer’s name in remitter.name.
• In fixed-remitter corridors, use customerComments for customer name and invoice/order reference.
• Keep text short (less than 30 characters), alphanumeric, and avoid special symbols.
• Test visibility in your key corridors before going live.

Please note:

• Corridor rules: Some corridors enforce fixed remitter names or block reference details.
• Recipient banks: Some banks cut short or remove details, even if Nium forwards them.
• Formatting not guaranteed: The final layout of details always depends on the recipient’s bank.

FAQ

Q: How do I make sure my customer’s name appears?**
A: Include it in remitter.name. If the corridor doesn’t allow a remitter.name, add it to customerComments.

Q: What happens if I don’t pass customerComments in fixed-remitter corridors?**
A: Nium auto-populates <Remitter Name> and Nium Transaction ID.

Q: How will recipients recognize the transaction?**
A: Through the sender name, your comments, or system generated reference details references like UTRs.

Q: Why does visibility differ across corridors?**
A: Each clearing system and bank has its own rules for displaying sender and reference details.

Q: What if text exceeds corridor limits?**
A: It may be cut short by the bank.

Next steps

• See Payouts for details on how to create transactions.
• Always send the remitter.name.
• For corridors with fixed remitter names, include text that'll help you identify the transaction in customerComments (e.g. Sender name, Transaction ID, UTR, etc.).
• Share these details with your Ops and Treasury teams to align how transactions are reconciled.