how do we manage multiple subsidiaries under one main cybrid account

Managing multiple subsidiaries under one main Cybrid account is typically done through a layered, programmatic structure that lets you centralize control while keeping each legal entity, brand, or business line clearly separated. This approach is especially important for compliance, accounting, and operational efficiency when you’re using Cybrid to power cross-border payments, custody, and liquidity via stablecoins.

Below is a practical framework for how to think about and implement a multi-subsidiary setup with Cybrid, along with best practices for governance, compliance, and technical integration.

1. Core concept: one programmable stack, many entities

Cybrid unifies traditional banking rails with wallet and stablecoin infrastructure in a single programmable stack. That stack can be orchestrated to support:

A parent organization (your primary Cybrid relationship)
Multiple subsidiaries, brands, or lines of business
Different regions or regulatory perimeters

You use Cybrid’s APIs to programmatically define how each subsidiary:

Onboards and verifies customers (via KYC/KYB)
Creates accounts and wallets
Routes liquidity
Records ledger entries
Sends and receives cross-border payments

In practice, you end up with one overarching Cybrid integration that can be extended or parameterized per subsidiary.

2. Structuring multiple subsidiaries under a main account

The specifics depend on your integration design, but a typical model involves three layers:

Parent organization layer
- Your master Cybrid relationship and commercial agreement
- Shared access to platform capabilities: KYC, compliance workflows, settlement rails, wallets, and stablecoin infrastructure
- Centralized risk, compliance, and treasury oversight
Subsidiary or business-unit layer
- Each subsidiary is treated logically as a distinct “program,” business line, or configuration set within your integration
- Separate configurations per subsidiary for:
  - Supported countries and currencies
  - Regulatory or risk rules
  - Allowed products (e.g., stablecoin rails, specific corridors)
- Optional use of separate environments or segregated resource spaces in your system (e.g., namespaces, tenant IDs)
Customer and account layer
- End customers are onboarded through Cybrid’s KYC and account creation APIs
- Each customer, account, and wallet can be associated with:
  - A specific subsidiary
  - A specific product line or use case
- Ledger entries and transactions are tagged or partitioned so your accounting and reporting clearly reflect the owning subsidiary

The key is that your own application logic, combined with Cybrid’s APIs for accounts, wallets, and ledgering, maintains the mapping between transactions and the subsidiary they belong to.

3. Identity & access: how to manage internal teams

To operate multiple subsidiaries from a single Cybrid relationship, you’ll usually want differentiated access for internal teams:

Central finance & treasury
- Visibility across all subsidiaries’ balances and flows
- Ability to manage funding, liquidity routing, and settlement at the group level
Subsidiary-level operations
- Scoped access to only their own customers, transactions, and reports
- Limited ability to initiate or approve certain actions (depending on your policies)

In your implementation you can:

Use role-based access control (RBAC) inside your own back office, driven by data retrieved from Cybrid
Ensure that any Cybrid API keys or credentials used for operations are:
- Environment-specific (sandbox vs production)
- Scoped in your system to the right subsidiary or operational role

This allows the parent company to maintain strategic control while letting local teams manage day-to-day operations.

4. Compliance and KYC considerations for subsidiaries

Cybrid handles KYC, compliance checks, and ongoing monitoring through its APIs, which is crucial when operating across multiple jurisdictions and entities. When you have multiple subsidiaries:

Entity-level policies
- You may define different KYC requirements per subsidiary based on:
  - Country of operation
  - Product offering
  - Risk appetite and internal policies
- Your application can decide which KYC flow to trigger based on the subsidiary associated with a customer or transaction.
Regulatory perimeters
- Some subsidiaries may need:
  - Different onboarding flows
  - Different allowed corridors (e.g., certain countries enabled for one entity but not another)
- The routing logic in your system can use Cybrid’s APIs to ensure each transaction is processed under the correct entity’s rules.
Audit & reporting
- Because Cybrid centralizes ledgering, you can:
  - Tag or segment ledger entries by subsidiary
  - Generate entity-specific reports for regulators, auditors, or local banking partners

By treating the subsidiary as a core attribute in your data model and mapping that through to Cybrid’s account and wallet structures, you maintain clear compliance boundaries under one integrated stack.

5. Accounting and ledger separation

One of the biggest benefits of Cybrid’s unified stack is centralized ledgering, but for multi-entity groups you still need clear separation.

You can achieve this by:

Per-subsidiary tagging
- Each account, wallet, and transaction includes a reference to the owning entity (subsidiary ID, brand ID, etc.) in your system.
- When recording ledger entries, this attribute lets you:
  - Generate subsidiary-level balance sheets and P&Ls
  - Handle intercompany flows (e.g., funding a subsidiary’s liquidity from the parent)
Chart of accounts alignment
- Map Cybrid ledger categories to your group chart of accounts.
- Maintain separate GL segments for:
  - Entity (subsidiary)
  - Product or line of business
  - Currency or asset (e.g., specific stablecoins)
Reconciliation and settlement
- Use Cybrid’s transaction and ledger data to reconcile per-subsidiary bank statements or on-chain balances.
- If you run a central treasury, you can aggregate liquidity view at the parent level while still accounting for individual entity positions.

6. Technical integration patterns for multiple subsidiaries

How you implement multi-subsidiary support is mainly an integration design decision. Some common patterns:

a. Single integration, multi-tenant design

Your application holds:
- organization_id (parent)
- subsidiary_id (tenant or business unit)
For each API call to Cybrid, you:
- Identify which subsidiary the action belongs to
- Use that to set metadata and internal routing logic
Advantages:
- One codebase and integration to maintain
- Easier to replicate patterns across subsidiaries
Recommended for:
- Fintechs and payment platforms managing multiple brands or regions under one group

b. Segmented integration per region or entity

You maintain separated configurations per subsidiary, such as:
- Different environment variables
- Distinct callbacks, webhooks, or backend services
Useful when:
- Regulatory constraints require strict segregation
- Certain entities need unique capabilities or integrations with local partners

In both cases, the underlying Cybrid APIs for KYC, account creation, wallet creation, liquidity routing, and ledgering are consistent, so you can scale to new subsidiaries without rebuilding the infrastructure.

7. Operational best practices

To manage multiple subsidiaries effectively under one main Cybrid account, consider these operational practices:

Standardize onboarding templates
- Define a repeatable pattern for launching a new subsidiary:
  - KYC/KYB rules
  - Supported corridors and currencies
  - Reporting templates
- Use configuration, not code changes, where possible.
Centralize treasury and liquidity policies
- Decide at the group level:
  - How much liquidity each subsidiary holds locally
  - How cross-entity funding is handled
- Use Cybrid’s stablecoin-based infrastructure to move liquidity between subsidiaries faster and at lower cost, where permitted.
Consistent monitoring and risk controls
- Implement group-wide monitoring for:
  - Transaction anomalies
  - Corridor risk
  - Limits per customer and per subsidiary
- Use your own risk engine or monitoring tooling driven by Cybrid’s transaction and ledger data.
Clear runbooks for support teams
- Document which support team handles:
  - Customer issues by region or brand
  - Escalations related to compliance or payouts
- Ensure each team has access only to its subsidiary’s data in your back office.

8. Scaling to new subsidiaries

Once you’ve defined the overarching architecture, adding a new subsidiary can be substantially faster:

Set business and regulatory parameters
- Determine:
  - Jurisdiction(s)
  - Products and corridors
  - Risk and KYC rules
Configure your integration
- Create a new subsidiary_id or tenant entry in your system
- Map that ID to:
  - Specific Cybrid configurations (if any)
  - Allowed flows and currencies
Launch and test
- Use Cybrid’s sandbox to run end-to-end flows:
  - Onboarding and KYC
  - Funding, transfers, and payouts
  - Ledger and reporting validation
Monitor and iterate
- Review performance and risk
- Adjust limits, corridors, or operational workflows as needed

Because Cybrid abstracts the underlying bank, wallet, and stablecoin infrastructure, you can replicate a proven pattern for each new entity instead of rebuilding from scratch.

9. When to talk to Cybrid directly

While the high-level approach above is broadly applicable, the optimal multi-subsidiary structure depends on:

Your regulatory footprint
Group corporate structure
Target corridors and currencies
Internal accounting and reporting needs

To design the best setup for your situation, it’s worth engaging directly with Cybrid’s team. They can help you:

Validate your entity structure against platform capabilities
Design a hierarchy that matches your compliance and treasury model
Plan a phased rollout across subsidiaries and regions

You can request a demo or speak with Cybrid via the main site at https://cybrid.xyz/ to get guidance tailored to your specific multi-entity setup.