> ## Documentation Index > Fetch the complete documentation index at: https://doc.engagexpay.com/llms.txt > Use this file to discover all available pages before exploring further. # Sender & Receiver Relationships > Understanding relationship types between senders and beneficiaries for compliant transactions 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. > [!NOTE] > > 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: | Relationship | Description | | - | - | | `EMPLOYEE` | For payments to employees such as salaries, wages, bonuses, or reimbursements | | `FREELANCER` | For payments to independent contractors or freelance workers for services rendered | | `GIG_WORKER` | For payments to gig economy workers (e.g., delivery drivers, task-based workers) | | `AFFILIATE` | For payments to affiliate marketers or partners in your affiliate program | | `CUSTOMER` | For payments to customers such as refunds, rewards, or cashback | | `FAMILY_MEMBER` | When a business owner is sending funds to their family member | | `FRIEND` | When a business owner is sending funds to a friend | | `SELF` | When a business owner is transferring funds to their personal account | | `OTHER` | For any relationship not covered by the above categories | > [!WARNING] > > 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 > [accordion] Payroll & Compensation > > Use `EMPLOYEE` for regular payroll, bonuses, commissions, or expense reimbursements to full-time or part-time employees. > [accordion] Contract Work > > Use `FREELANCER` for payments to independent contractors, consultants, or freelance professionals. Use `GIG_WORKER` for platform-based or task-specific workers. > [accordion] Customer Transactions > > Use `CUSTOMER` for refunds, loyalty rewards, cash-back payments, or settlement of customer disputes. > [accordion] Marketing & Partnerships > > 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: | Relationship | Description | | - | - | | `SUPPLIER` | For payments to suppliers for goods or raw materials | | `VENDOR` | For payments to vendors for products or inventory | | `SERVICE_PROVIDER` | For payments to service providers (e.g., SaaS, consulting, professional services) | | `MERCHANT` | For payments to merchants or retailers | | `CONTRACTOR` | For payments to business contractors or contracting firms | | `CUSTOMER` | For payments to business customers (e.g., refunds, rebates) | | `SUBSIDIARY` | For transfers to a subsidiary or controlled entity | | `PARENT_COMPANY` | For transfers to the parent company or holding company | | `AFFILIATE_BUSINESS` | For payments to affiliated businesses or sister companies | | `BANK_ACCOUNT` | For transfers to your own business bank account | | `OTHER` | For any business relationship not covered by the above categories | > [!WARNING] > > 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 > [accordion] Supply Chain & Procurement > > Use `SUPPLIER` for raw materials, `VENDOR` for finished goods or inventory, and `MERCHANT` for retail purchases. > [accordion] Professional Services > > Use `SERVICE_PROVIDER` for payments to consultants, agencies, SaaS platforms, or any professional service organization. > [accordion] Corporate Structure > > Use `SUBSIDIARY` for transfers to owned entities, `PARENT_COMPANY` for transfers to your holding company, and `AFFILIATE_BUSINESS` for sister companies or partnerships. > [accordion] Internal Transfers > > 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: | Relationship | Description | | - | - | | `MERCHANT` | For payments to merchants for purchases of goods or services | | `SERVICE_PROVIDER` | For payments to service providers (e.g., utilities, subscriptions, professional services) | | `SUPPLIER` | For payments to suppliers (typically for small business owners) | | `VENDOR` | For payments to vendors for products | | `BROKER` | For payments to brokers (e.g., insurance, real estate, investment) | | `EXCHANGE` | For payments to currency exchanges, crypto exchanges, or trading platforms | | `WALLET` | For payments to digital wallets or payment service providers | | `BANK_ACCOUNT` | For transfers to your own business bank account | | `OTHER` | For any relationship not covered by the above categories | > [!WARNING] > > 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 > [accordion] Commerce & Purchases > > Use `MERCHANT` for online or retail purchases, `SERVICE_PROVIDER` for subscription services, utilities, or professional services. > [accordion] Financial Services > > Use `BROKER` for insurance premiums or investment services, `EXCHANGE` for currency or crypto trading, and `WALLET` for loading digital wallets. > [accordion] Small Business Operations > > 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: | Relationship | Description | | - | - | | `FAMILY_MEMBER` | For transfers to family members (e.g., spouse, children, parents, siblings) | | `FRIEND` | For transfers to friends or acquaintances | | `SELF` | For transfers between your own accounts | | `OTHER` | For any relationship not covered by the above categories | > [!WARNING] > > 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 > [accordion] Family Support > > Use `FAMILY_MEMBER` for remittances, allowances, gifts, or financial support to immediate or extended family members. > [accordion] Personal Transfers > > 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` ```json Example 1: B2I Other theme={null} theme={null} { "relationship": "OTHER", "relationship_remarks": "Payment to independent brand ambassador for social media marketing campaign" } ``` ```json Example 2: B2B Other theme={null} theme={null} { "relationship": "OTHER", "relationship_remarks": "Payment to joint venture partner for shared project revenue distribution" } ``` ```json Example 3: I2B Other theme={null} theme={null} { "relationship": "OTHER", "relationship_remarks": "Payment to crowdfunding platform for investment in startup" } ``` ```json Example 4: I2I Other theme={null} theme={null} { "relationship": "OTHER", "relationship_remarks": "Payment to roommate for shared utility bills and rent contribution" } ``` > [!TIP] > > **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: | Category | Available Relationships | | - | - | | **B2I** (Business to Individual) | `EMPLOYEE`, `FREELANCER`, `GIG_WORKER`, `AFFILIATE`, `CUSTOMER`, `FAMILY_MEMBER`, `FRIEND`, `SELF`, `OTHER` | | **B2B** (Business to Business) | `SUPPLIER`, `VENDOR`, `SERVICE_PROVIDER`, `MERCHANT`, `CONTRACTOR`, `CUSTOMER`, `SUBSIDIARY`, `PARENT_COMPANY`, `AFFILIATE_BUSINESS`, `BANK_ACCOUNT`, `OTHER` | | **I2B** (Individual to Business) | `MERCHANT`, `SERVICE_PROVIDER`, `SUPPLIER`, `VENDOR`, `BROKER`, `EXCHANGE`, `WALLET`, `BANK_ACCOUNT`, `OTHER` | | **I2I** (Individual to Individual) | `FAMILY_MEMBER`, `FRIEND`, `SELF`, `OTHER` | > [!NOTE] > > **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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.