Virtual Identity & Access
In a multi-provider environment, identity becomes complex. Each bank has its own customer ID, each PSP its own merchant ID. Hyperscale creates a virtual identity layer that abstracts these provider-specific identities into a unified model your application works with.
Virtual Identity
Abstraction Layer
A virtual identity is an abstraction over provider-specific accounts. When you create a customer in Hyperscale, we create corresponding identities at downstream providers automatically.
Identity Mapping
Each Hyperscale customer ID maps to multiple provider-specific IDs. The mapping is maintained in our identity registry, invisible to your application.
Portability
Virtual identities are portable across providers. Switch from one bank to another without changing your integration — we handle identity migration.
Unified Access
One customer object provides access to all provider capabilities: KYC, accounts, cards, payments. No provider-specific customer onboarding needed.
Identity Mapping Example
cus_abc123Hyperscale Customer
BANK-001-CUST-789PSP-MER-456KYC-VER-123Virtual Accounts & Sub-Ledgers
Virtual accounts provide the abstraction; sub-ledgers track the positions. Inspired by Modern Treasury and Treasury Prime architectures.
Virtual Account Numbers
Each customer account gets a unique virtual IBAN. Funds are held in the partner bank's pooled account, with Hyperscale maintaining the sub-ledger position.
Format: SA00HYPXXXXXXXXXXXXXReal-time Balance
Balances are calculated from the sub-ledger in real-time. Every transaction updates the position immediately.
Latency: <100ms for queriesMulti-Currency
Virtual accounts support multiple currencies. Each currency position is tracked separately with automatic FX when needed.
SAR, USD, EUR + 20 moreReconciliation
Automated daily reconciliation between Hyperscale sub-ledger and partner bank statement. Discrepancies flagged immediately.
T+0 reconciliationSub-Ledger Structure
Partner Bank
Pooled Account
SAR 10,000,000
Sub-ledger positions must equal pooled balance
Counterparty Management
Counterparties are external parties in transactions. Every counterparty is screened against sanctions and watchlists before transactions proceed.
Customer vs Counterparty
Customer
Your user. Verified, KYC'd, has accounts with you.
Counterparty
External party. Recipient of transfers, sender of payments.
Screening Checks
Access Control Models
Choose the access control model that fits your needs. Most applications start with RBAC and add ABAC for fine-grained control.
Role-Based Access Control
Assign users to roles (admin, developer, viewer) with predefined permissions. Simplest model for most use cases.
developer can read accounts, write transactionsAttribute-Based Access Control
Fine-grained access based on attributes: user department, resource sensitivity, time of day, location.
if user.department == 'treasury' && amount < 100000Resource-Level Permissions
Permissions scoped to specific resources. User A can access Customer X but not Customer Y.
user.can_access(customer_id: 'cus_xxx')Entity Lifecycle
All entities follow a standard lifecycle with explicit state transitions.
created
Initialized but not yet active
active
Fully operational
suspended
Temporarily frozen
closed
Permanently closed