Verto Architecture Basics

Use this page to choose the right Verto model, understand how account context works, and map wallets, collections, FX, and payouts before you build.

✅ Start with these questions

Answer these questions before you design your integration:

1. Are you moving your own funds or acting for downstream customers?
2. Who owns KYB or KYC for the end user: your business or Verto?
3. Will money be collected into a master wallet, a sub-account wallet, or both?
4. Do you need to convert funds before you pay out or settle balances?

📐 The Two-Dimensional Integration Model

Every Verto integration is shaped by two decisions: who the funds belong to operationally and who owns customer verification.

1. The Business Model (Operational Intent)

• First-Party (Direct): You are moving your own business funds, such as paying suppliers or managing treasury.
• Third-Party (Platform): You are moving funds on behalf of downstream customers, such as merchants, sellers, or business users.

This choice determines whether you mainly operate from your master wallet or need isolated customer contexts through sub-accounts.

2. The Verification Model (Regulatory Logic)

• Partner KYB (Fintech): You verify your customers and Verto relies on your compliance framework.
• Verto KYB (Platform): Verto verifies your customers as part of the regulated onboarding flow.

This decision affects onboarding, approval requirements, and which downstream flows your account can use.

In practice, these two dimensions tell you whether to build a direct treasury flow, a customer-scoped platform flow, or a hybrid model that combines both.

🏛️ Identity vs. Context (Atlas)

The Atlas framework uses a hierarchical ledger model so one integration can operate either in its own business context or in a downstream customer context.

• Master Account: Your primary business identity and treasury layer.
• Sub-Account: A segregated customer context for one downstream user or business.
• Context Routing: Use the X-Sub-Account-Id header to route a request into the correct sub-account without creating separate API credentials for every customer.

Use the master account when the wallet, funds, and payout belong to your own business. Use sub-account context when the wallet, receiving details, beneficiary, statement, or payout should belong to a downstream customer.

💎 The Atomic Primitives

How the primitives work together

Most integrations follow this sequence:

1. Create identity context: Use your master account or create a sub-account.
2. Provision a wallet: Hold balances in the currency you need.
3. Collect or fund value: Receive money through account details or fund the wallet through your existing treasury flow.
4. Convert if needed: Exchange value into the payout, settlement, or operating currency.
5. Move funds out: Send money to a beneficiary or continue into the next treasury operation.

Not every integration uses every primitive, but nearly every integration starts by choosing the right account context and wallet structure first.

🎯 Next Steps