Skip to main content
When creating a beneficiary and initiating a transaction, it’s essential to accurately specify the relationship between the sender and the receiver. This information is required for compliance, regulatory reporting, and fraud prevention purposes.
The relationship between the beneficiary and sender is mandatory for processing transactions. Providing accurate relationship information helps ensure smooth transaction processing and compliance with international financial regulations.

​
Relationship Categories

Relationships are categorized based on whether the sender and receiver are businesses or individuals:
  • B = Business entity
  • I = Individual person
This creates four distinct relationship categories:
  1. B2I - Business to Individual
  2. B2B - Business to Business
  3. I2B - Individual to Business
  4. I2I - Individual to Individual

​
Business to Individual (B2I)

When a business is sending funds to an individual, use one of the following relationship types:
When using OTHER as the relationship value, you must provide the relationship_remarks field with a clear explanation of the actual relationship. Failing to do so may result in transaction delays or rejections.

​
B2I Use Cases

Use EMPLOYEE for regular payroll, bonuses, commissions, or expense reimbursements to full-time or part-time employees.
Use FREELANCER for payments to independent contractors, consultants, or freelance professionals. Use GIG_WORKER for platform-based or task-specific workers.
Use CUSTOMER for refunds, loyalty rewards, cash-back payments, or settlement of customer disputes.
Use AFFILIATE for commission payments to affiliate partners, referral bonuses, or performance-based incentives.

​
Business to Business (B2B)

When a business is sending funds to another business entity, use one of the following relationship types:
When using OTHER as the relationship value, you must provide the relationship_remarks field with a clear explanation of the actual relationship. Failing to do so may result in transaction delays or rejections.

​
B2B Use Cases

Use SUPPLIER for raw materials, VENDOR for finished goods or inventory, and MERCHANT for retail purchases.
Use SERVICE_PROVIDER for payments to consultants, agencies, SaaS platforms, or any professional service organization.
Use SUBSIDIARY for transfers to owned entities, PARENT_COMPANY for transfers to your holding company, and AFFILIATE_BUSINESS for sister companies or partnerships.
Use BANK_ACCOUNT when moving funds between your own business accounts.

​
Individual to Business (I2B)

When an individual is sending funds to a business entity, use one of the following relationship types:
When using OTHER as the relationship value, you must provide the relationship_remarks field with a clear explanation of the actual relationship. Failing to do so may result in transaction delays or rejections.

​
I2B Use Cases

Use MERCHANT for online or retail purchases, SERVICE_PROVIDER for subscription services, utilities, or professional services.
Use BROKER for insurance premiums or investment services, EXCHANGE for currency or crypto trading, and WALLET for loading digital wallets.
Individual business owners may use SUPPLIER or VENDOR when purchasing inventory or supplies, or BANK_ACCOUNT when funding their business account.

​
Individual to Individual (I2I)

When an individual is sending funds to another individual, use one of the following relationship types:
When using OTHER as the relationship value, you must provide the relationship_remarks field with a clear explanation of the actual relationship. Failing to do so may result in transaction delays or rejections.

​
I2I Use Cases

Use FAMILY_MEMBER for remittances, allowances, gifts, or financial support to immediate or extended family members.
Use FRIEND for splitting bills, repaying loans, or sending gifts to friends. Use SELF for transfers between your own accounts.

​
The OTHER Relationship Type

The OTHER relationship type serves as a catch-all for legitimate relationships that don’t fit into the predefined categories. However, using OTHER requires additional documentation.

​
Requirements When Using OTHER

When you specify OTHER as the relationship type, you must include the relationship_remarks field in your API request. This field should contain:
  1. Clear description - Explain the actual relationship in plain language
  2. Sufficient detail - Provide enough context for compliance review
  3. Legitimate purpose - Ensure the relationship and transaction purpose are lawful

​
Examples of Valid relationship_remarks

Best Practice: Whenever possible, use the specific predefined relationship types rather than OTHER. This helps ensure faster transaction processing and reduces the likelihood of compliance holds.

​
Quick Reference Table

Here’s a consolidated view of all relationship types across categories:
Remember: All ENUM values must be provided in ALL CAPS as shown in the table above.

​
Need Help?

If you’re unsure which relationship type to use for your specific use case:
  1. Review the descriptions and examples provided in this guide
  2. Choose the most accurate predefined relationship type whenever possible
  3. Use OTHER only when no predefined type accurately describes the relationship
  4. When using OTHER, provide detailed and honest information in relationship_remarks
  5. Contact our support team if you need clarification on specific scenarios
For questions or support, please reach out to our team or consult your integration documentation.