Trust Architecture
The four-layer trust model powering Hyperscale.
Hyperscale operates as a Technical Service Provider (TSP) under SAMA supervision. We don't hold funds — that's the partner bank's role. Instead, we provide the infrastructure layer that enables fintechs to access banking services without managing the complexity themselves.
Four-Layer Trust Model
Click each layer to explore its responsibilities and trust relationships.
Trust Chain: Each layer trusts the layer above it and is trusted by the layer below. The Partner Bank is the ultimate trust anchor, licensed by SAMA. Hyperscale TSP operates under this umbrella, providing infrastructure to Fintech clients who serve end users.
What Each Layer Does
Clear separation of concerns. Each layer has explicit responsibilities — and explicit boundaries.
Partner Bank (L1)
Does
- •Holds actual customer funds in pooled/omnibus accounts
- •Bears prudential and regulatory risk under SAMA
- •Maintains required capital buffers and reserves
- •Provides banking license coverage for deposit-taking
- •Executes final settlement of transactions
- •Reports to SAMA on regulatory requirements
Does Not
- •Build or maintain fintech products
- •Manage virtual ledgers or sub-accounts
- •Handle API orchestration or routing
- •Store downstream provider credentials
Hyperscale TSP (L2)
Does
- •Maintains virtual ledger for client sub-accounts
- •Orchestrates 40+ provider APIs through single interface
- •Manages credential custody vault (HSM-backed)
- •Automates KYC, AML, and compliance workflows
- •Routes transactions based on cost, availability, compliance
- •Provides real-time reconciliation with partner bank
Does Not
- •Hold actual customer funds (funds stay with bank)
- •Bear prudential risk or capital requirements
- •Make independent regulatory decisions
- •Operate without partner bank relationship
Fintech Client (L3)
Does
- •Integrates via single Hyperscale API key
- •Builds user-facing products and experiences
- •Manages own user authentication and sessions
- •Defines product rules and business logic
- •Accesses all providers through unified API
Does Not
- •Manage downstream provider credentials
- •Handle direct bank or PSP integrations
- •Bear infrastructure or compliance burden
- •See or store provider tokens
End User (L4)
Does
- •Authenticates with fintech application
- •Receives consistent product experience
- •Benefits from all trust layers above
- •Grants consent for data access (Open Banking)
Does Not
- •Know about underlying infrastructure
- •Interact directly with banks or providers
- •Manage multiple credentials or accounts
- •Experience provider-specific differences
TSP Requirements under SAMA
Technical Service Providers must meet comprehensive operational, security, and governance requirements.
Operational
- Business continuity and disaster recovery plans
- Incident response procedures
- Change management controls
- Service level agreements with clients
Security
- Penetration testing and vulnerability assessments
- Encryption at rest and in transit
- Access control and identity management
- Security monitoring and logging
Data
- Data residency within Saudi Arabia
- PDPL compliance for personal data
- Data retention and deletion policies
- Cross-border transfer restrictions
Governance
- Risk management framework
- Internal audit function
- Regulatory reporting obligations
- Third-party oversight procedures
Security Perimeter
Defense in depth across network, application, service, and data layers.
Network
- →WAF with OWASP ruleset
- →DDoS protection
- →IP allowlisting for admin
- →TLS 1.3 minimum
API Gateway
- →Rate limiting per client
- →Request validation
- →Authentication enforcement
- →API versioning
Service Mesh
- →mTLS between services
- →Service identity verification
- →Traffic encryption
- →Circuit breaking
Data
- →AES-256-GCM encryption
- →HSM key management
- →Field-level encryption
- →Tokenization
Built for trust
Every layer designed with clear boundaries and explicit responsibilities.