Info
In this file, we describe exactly how we solve the problems of “weak mobile banking and outdated IT systems”: the Core+Modules architecture, the modular product model, the technology stack, the approach to real-time, security, observability, and scalability.
Table of contents
- 1. Key theses
- 2. The essence of the problem
- 3. The DARCA approach: platform core + pluggable modules
- 4. Platform architecture (high level)
- 5. Core (shared core): what it contains and why exactly this
- 6. Modules (pluggable extensions): what they really are
- 7. Real-time mechanics: event-driven instead of batch
- 8. Durable workflows: how we build “non-breakable” processes
- 9. API-first and contract-driven design
- 10. Security-by-design (multi-layer security)
- 11. Reliability & Observability (stability as a standard)
- 12. Technology stack
- 13. UI/UX and the team
- 14. Summary: how this addresses the research problems
1. Key points
Core platform concepts: a unified transactional core, pluggable modules, a real-time approach, and built-in security.
We are building a next-generation banking platform and addressing the limitations of legacy IT not through “cosmetic improvements,” but through architecture. At the foundation lies a unified transactional core (Core), which is responsible for the system’s immutable properties (accounting, security, access control, audit), and pluggable functional modules (Modules), which extend the product without breaking the core.
We design the platform as a real-time system: transaction statuses, critical scenarios, and channel synchronization are built on a streaming model (events/workflows), rather than batch processing “windows.” This makes mobile banking fast and predictable: the user sees a clear status, the reason, and the next step, instead of “please wait while processing.”
We assume from the outset that there will be a lot of functionality, but different users need different things. Therefore, our product model is modular: a user or a company enables only those modules that are truly needed (for example, P2P, Earn/staking, business limits and approvals, reporting and integrations). As a result, the application does not turn into an overloaded all-in-one tool, while the platform can grow in features and markets without an exponential increase in interface complexity.
We build the system so that new functionality can be added quickly and safely. This is achieved through contract-based design (API-first + event contracts), managed access policies, and isolation of modules by permissions, metrics, and failure domains. Security and compliance are embedded into the foundation: a risk engine (allow/step-up/hold/deny), immutable audit of critical actions, protocol-level protections against duplicates and replays, and centrally managed rules for limits and access.
2. The core of the problem
An analysis of why mobile banking is weak: UX issues, lack of real-time, instability, and architectural limitations of legacy systems.
2.1. What breaks mobile banking
Warning
We see that “weak mobile banking” almost always consists of several recurring components:
-
Poor UX and overload
The application tries to be “everything for everyone”: too many unnecessary screens, inconsistent logic, and too many steps in basic scenarios (transfers, exchanges, limit management). As a result, the user spends effort navigating the interface instead of managing money.
-
Lack of a real-time feeling
The user does not receive a clear status of “what is happening right now”: operations update with delays, history loads in “waves,” notifications arrive late. This is perceived as instability, even if the operation eventually completes successfully.
-
Poor performance and client instability
UI lag, long loading times, and errors in critical areas (login, confirmations, transaction statuses) directly undermine trust. The research specifically highlights that weak interfaces, limited functionality, and low performance remain a typical problem of banking applications.
-
Functional gaps between B2C and B2B
What is convenient for individuals often does not work for businesses: businesses need roles, limits, approvals, exports, and integrations. In the mobile channel, these are either missing, poorly implemented, or moved to an external “cabinet.”
2.2. What breaks IT
Danger
The mobile banking problem is almost always a consequence of how a bank’s IT foundation is built.
-
Legacy core and monolithic architecture - outdated core systems are difficult to evolve: any change affects too many components, testing is expensive, and the risk of regressions is high. The research specifically notes that banks still use legacy languages (for example, COBOL) and inherited platforms, which increase fragility and complicate development.
-
Batch processing instead of a streaming model - many processes run in batches: balance updates, calculations, reconciliations, and statuses. As a result, the user interface often shows “what was last updated by a batch,” rather than “what is happening now.” The research directly describes legacy banks’ dependence on batch processing.
-
Fragmented data and a weak integration model - information is scattered across systems, with no single source of truth and no standard contract-based interaction. As a result, the rollout of new features (AI personalization, open banking/API, new payment scenarios) is slowed not by “lack of desire,” but by architectural constraints.
-
High operational cost of change - most resources are spent on “keeping the system running” rather than on product development. This is a typical picture of legacy IT.
-
Increased failure and security risks - when a system is complex, tightly coupled, and burdened with accumulated technical debt, it handles load worse, is less observable, and is harder to update from a security perspective.
2.3. Why “just rewriting the core” does not work
We consider the approach of “rewriting everything from scratch” to be incorrect, because in practice it means:
- a long-term project with high cost
- increased risk of instability during the transition
- parallel slowdown of product development (all attention shifts to migration)
Tip
That is why we choose a platform strategy:
We build a resilient Core-core with immutable invariants (accounting, security, access control, audit, transaction routing), while functional growth and rapid experimentation are implemented through plug-in modules, which can be released and updated independently, without breaking the core.
3. DARCA approach: platform core + pluggable modules
An architectural approach where a stable core provides immutable properties, while modules add functionality without complicating the foundation.
3.1. Core principle: Core + Modules
Info
We build the platform according to the principle “one shared core + pluggable modules”.
Two key components:
-
Core (core) - a stable foundation that provides the system’s immutable properties: correct asset accounting, security, access control, audit, basic payment scenarios, unified statuses, and telemetry.
-
Modules (modules) - extensions that add new product capabilities and verticals (P2P, Earn/staking, RWA, business functions, and so on) without “shaking” or complicating the core.
We do this deliberately, because in legacy banks the main problem is that any extension turns into a risky project that touches the entire monolith. For us, functional expansion happens around the core, not inside it.
3.2. Why modularity matters for the product
We assume from the start that there will be a lot of functionality, and that different segments will need different things. That is why we do not build a single “all-in-one machine” that shows everything to everyone.
Modularity gives the product:
-
Clean and fast interface - the base application remains lightweight: wallet, balances, transfers, history, security, notifications. Everything else is connected only when needed.
-
Personalization and growth without overload - the set of modules effectively becomes a “product profile” for the user: individuals connect one set, businesses another. The UI expands exactly where it is required.
-
Clear monetization - some modules can be paid (subscription, plan, fee), while the base functionality can remain free or low-cost. This is convenient for both users and the business.
3.3. Why modularity matters for development and operational resilience
Modularity is not only about the interface. It is a way to make the system manageable and resilient.
-
Independent releases - we can release and update a module without touching the core and without causing a global regression across the system.
-
Risk isolation - if a module degrades (error, load, instability), the core continues to operate. The module can be disabled for a cohort of users or rolled back without breaking core operations.
-
Team scaling and delivery speed - different teams can develop different modules in parallel, without blocking each other or creating a “release queue”.
-
Fast integration of new technologies - new technologies and directions (new payment rails, new networks, new AI models) are easier to add as a module or as an isolated component than by rewriting the core.
3.4. Future-proofing: we assume technology changes fast
Question
How do you build a system that can evolve without accumulating technical debt?
We start from reality: technologies, payment rails, compliance requirements, and user expectations change quickly. Therefore, we build the system so that:
- the core remains stable and changes rarely (only when it is truly necessary to change invariants)
- everything that changes quickly lives in modules and connects through contracts
- infrastructure components can be replaced without a “bank restart” (through layering, contracts, and isolation)
This is a fundamental difference from the legacy approach: we design not a “system for the current year”, but a platform that can evolve and expand without accumulating critical technical debt.
4. Platform architecture (high-level)
Architecture layers: Experience Layer, Core Platform Layer, Modules Layer, and Integration Layer, each with a clear role and independent evolution.
4.1. Architecture layers
Note
We build the platform as a set of layers, where each layer has a clearly defined role and can develop independently. This reduces coupling, accelerates change, and simplifies scaling.
4.1.1. Experience Layer (client applications and interfaces)
The layer responsible for user experience and fast interaction scenarios.
- Mobile (iOS/Android) - the primary product for B2C and part of B2B scenarios
- Web / Business console - corporate scenarios: roles, limits, approvals, reporting
- Backoffice / Support tools - operator, compliance, and support tools
- Partner / Developer portals - documentation and API/key management (for integrations)
Layer goal: fast, clear UX and unified patterns for working with operation statuses, errors, and security.
4.1.2. Core Platform Layer (platform core)
The layer of immutable invariants: what must be reliable and consistent for all modules and all users.
- Identity & Access (DARCA ID) - sessions, devices, MFA/passkeys, roles
- Ledger & Wallet Core - asset and balance accounting, immutable history
- Payments Orchestrator - unified routing of operations and statuses
- Risk & Compliance Core - risk decisions, limits, policies, audit
- Notifications Core - notifications and system events
- Observability & Audit Core - metrics, tracing, logging, audit trail
- Module Registry & Entitlements - enabling/disabling modules, versions, permissions, pricing
Layer goal: ensure that any module runs on a stable platform, rather than building its own mini-bank inside the bank.
4.1.3. Modules Layer (pluggable modules)
The layer of product verticals that grows and expands rapidly.
- Modules for individual users (P2P, Earn/staking, investment scenarios)
- Modules for businesses (role model, approvals, mass payouts, reporting)
- Modules by assets/networks/markets (new rails, new networks, new partners)
Layer goal: rapidly add functionality without risk to the core, release independently, and scale teams efficiently.
4.1.4. Integrations Layer (external systems and rails)
The integrations layer that connects the platform to the external world and partners.
- Fiat rails / partner banking - payment providers, partner banks, PSPs
- Blockchain gateways / nodes - network connectivity, confirmations, monitoring
- KYC/AML providers - checks, sanctions lists, risk signals
- Enterprise integrations - ERP/CRM/accounting, payment files, webhooks
Layer goal: standardize integrations so that new connections can be implemented quickly and without “manual workarounds”.
4.1.5. Infrastructure Layer (reliability, security, scaling)
The layer that ensures fault tolerance and operational manageability.
- containerization and orchestration, autoscaling
- observability (metrics/traces/logs), alerts and SLOs
- key/secret storage, network policies, mTLS
- redundancy, backups, DR procedures
Layer goal: ensure that the platform scales predictably and operates reliably even as load increases and geographic coverage expands.
4.2. Data and event flows (how everything “breathes”)
We connect the system through two primary “contractual channels” to avoid integration chaos:
| Channel | Usage | Examples |
|---|---|---|
| API contracts (synchronous) | Where an immediate response is required | login, balance request, operation creation, status request |
| Events (asynchronous) | Where real-time updates and loose coupling matter | operation status changes, risk decisions, notifications, analytics, module reactions |
Working pattern:
- a user or system action creates a command (API call)
- the core/module records state changes within its domains
- an event is then published and consumed by other services and modules
- the client sees changes via subscriptions/push notifications/status updates
This provides a real-time experience and allows new modules to be added simply by subscribing to the required events, without modifying the core.
4.3. Real-time loop (what we do fundamentally differently from legacy)
Example
In legacy systems, “everything reconciles” at the end of the operating day or in batch windows. We build differently:
- Real-time operation statuses - status changes are event-driven and immediately visible to the user
- Unified status model - consistent statuses and explanations across mobile, web, and support
- Event-driven channel synchronization - no desynchronization where “mobile shows one thing and the operator sees another”
- Streaming for analytics and antifraud - antifraud/scoring is powered by events, not batch exports
This is the foundation of strong mobile banking: UX becomes fast not because the interface was “tuned”, but because the entire platform operates in a real-time paradigm.
5. Core (shared core): what it contains and why exactly this
Core components: Identity, Ledger, Payments, Risk, Notifications, Observability, and Module Registry - each is critical for platform stability.
5.1. Identity & Access (DARCA ID)
This is the foundation of security and controllability. We do not “add security later” - we build it as a base layer of the platform.
What it includes:
- DARCA ID - user/company profile, statuses, KYC levels, segments
- Sessions and devices - device binding, new device control, trusted devices
- Confirmations - MFA/2FA, biometrics, passkeys (where applicable), step-up
- Roles and access - RBAC/ABAC, especially important for B2B (roles, permissions, limits)
- Action audit - who/what/when performed an action (critical for compliance and investigations)
Why this is in Core: any module must rely on a unified access, confirmation, and risk model. Otherwise, the platform fragments into inconsistent mini-products.
5.2. Ledger & Wallet Core
This is the “heart” of the platform: a unified model of assets, balances, and history. A strong mobile bank is impossible without strict accounting.
Invariants:
- a single account/wallet model for different currencies and assets
- strict transactionality: an operation is either fully executed or not executed at all
- immutable transaction history as the source of truth
- idempotency at the operation level (protection against duplicate debits)
Why this is in Core: accounting and balance correctness are fundamental invariants. Modules add scenarios but do not change accounting rules.
5.3. Payments Orchestrator + Internal Transfers
We build a unified layer that manages the entire operation lifecycle - from creation to final status - regardless of the rail (internal, partner, network).
What it includes:
- operation routing and a unified status state machine
- retries without duplicates, idempotency, replay protection
- a unified model of fees/limits/rules along the route
- internal instant transfers with zero fees, including by phone number/contacts
Why this is in Core: the platform must provide a consistent end-to-end operations and status flow for all modules. Otherwise, each feature would implement payments in its own way.
5.4. Risk & Compliance Core
The layer that makes real-time decisions: “allow / require confirmation / hold / deny”.
What it includes:
- risk decisioning: allow / step-up / hold / deny
- limits by operations/counterparties/countries/devices/roles
- compliance layer (KYC/AML, sanctions checks via providers)
- audit of “why the decision was made” (traceability)
Why this is in Core: risk and compliance are mandatory load-bearing elements of the platform, not optional features.
5.5. Notifications & Messaging Core
Notifications are part of UX and part of security. We implement this as a platform service.
What it includes:
- push/email/SMS/messengers/in-app
- event-based triggers (operation statuses, logins, device changes)
- user notification settings and templates
Why this is in Core: a unified notification system guarantees consistent and predictable behavior across all modules and channels.
5.6. Observability & Audit Core
We treat operations as part of the product: being able to see issues, understand their causes, and recover quickly.
What it includes:
- end-to-end metrics/logs/traces
- SLOs and alerts for critical operations and services
- an immutable audit trail for critical actions and decisions
Why this is in Core: without observability and audit, any complex system eventually turns into “error chaos”.
5.7. Module Registry & Entitlements
This is the mechanism that turns modularity into a manageable system.
What it includes:
- a catalog of modules (id, versions, dependencies, compatibility)
- eligibility (country, KYC level, risk profile, pricing plan)
- entitlements (which rights are granted on enablement and revoked on disablement)
- rollout control (cohorts, feature flags, instant disable/rollback)
Why this is in Core: without a registry and entitlements, a “modular platform” does not exist - it would just be a set of disconnected features.
5.8. Base App Capabilities (Default Modules) - base application features enabled by default
Note
It is important to distinguish between the platform Core and base product capabilities that are enabled “out of the box”. We define these capabilities as default modules: the user receives them immediately, but architecturally they are built on top of the Core and can evolve independently, without turning the core into a monolith.
What is included by default (as the base application package):
-
Instant internal transactions (zero fees)
- instant internal transfers
- transfers by phone number/contacts
- instant status notifications
-
Fiat and crypto exchange + favorable rate notifications
- instant in-app exchange
- rate/price alerts
-
Funds reservation (goal/time-based) - “savings pots/goals”
-
Bill payments and recurring payments
- automatic bill payments
- scheduled auto-transfers to other users
-
Reports and analytics (including a “monthly wrapper” format)
- spending/categories/dynamics
- period reports and a “monthly wrap”
-
Insufficient funds prediction (cashflow signals and warnings)
-
Customizable interface templates aligned with user goals (UX personalization UX)
-
Document storage (Document Vault inside the application)
-
Instant chat on any application screen (support/concierge/assistant)
- fast access to support without leaving the current flow
- a single, contextual entry point for help and guidance
Why this is here (in the Core section): these capabilities are a baseline standard for a mobile bank and should be available to most users immediately. However, we define them as “default modules” to preserve the core idea: the product grows modularly rather than becoming a monolith.
Everything that is not required for all users (gamification, stories, concierge/AI chat, rankings, cards, etc.) is moved to the Modules section as optional extensions.
6. Modules (plug-in extensions): what they really are
Modules as self-contained product blocks: financial, business functions, content, support, and cards - each with independent releases and risk isolation.
6.1. Principle: a module is a product block that extends the platform without breaking the Core
Note
A module is not “a couple of screens” and not “a single feature”. We define a module as a self-contained product block that:
- adds new scenarios and interface (UX/UI)
- has its own business logic and services
- connects to the Core via contracts (API + events)
- accesses data strictly through entitlements and policies
- has its own metrics, SLOs, and the ability to be disabled quickly
In other words, a module is a unit of scaling simultaneously for:
| Aspect | Meaning |
|---|---|
| Product | new verticals and features |
| Development | independent releases and updates |
| Operations | degradation isolation and fast rollback |
| Monetization | pricing/subscriptions/fees where appropriate |
6.2. Categories of modules (how we group extensions)
6.2.1. Financial Modules (financial scenarios)
- P2P / Exchange - advanced exchange scenarios, P2P markets, OTC flows
- Earn / Staking - yield products, staking/earn, terms and constraints
- Invest / Portfolio - portfolio, goals, strategies, risk profile (if enabled)
- RWA / Tokenization - asset tokenization, issuance/management, asset showcase
6.2.2. Business Modules (B2B layer)
- Roles & Permissions for Teams - roles, departments, access rights
- Approvals (Four-Eyes) - payment and operation approvals
- Limits & Policies - limits at role/team/counterparty level
- Mass Payments / Payroll - mass payouts, payroll projects
- Invoices / Reconciliation - invoices, reconciliation, exports, reports
- API / Webhooks - business integrations (ERP/CRM/accounting)
6.2.3. Engagement & Content Modules (content and engagement)
Warning
Anything that is not mandatory for all users and can overload the product is made optional:
- Gamification - achievements, missions, educational games, “tamagotchi/RPG” mechanics
- Stories / Feed - stories and content blocks
- Rating / Social - ratings and social mechanics
6.2.4. Support & Concierge Modules (advanced support)
We keep the base chat in “default modules”, but advanced scenarios are implemented as modules:
- Concierge - personal assistance, premium scenarios
- AI Assistant - assistant/neural network with context, hints, and workflows
6.2.5. Cards & Payments Modules (cards and spending)
- Crypto card / spending - card and crypto-based purchases
Tip
These components almost always depend on partners, jurisdictions, and regulation, which is why we keep them as a module.
6.3. How a module is enabled by the user (Module Marketplace → entitlements → UI)
Enabling a module is a controlled process, not just “showing a screen”.
-
Module Marketplace - the user sees the description, terms, constraints, risks, and requirements (for example, KYC level)
-
Eligibility check - before activation we verify:
- country/region
- KYC level/account status
- risk profile and restrictions
- pricing plan/subscription (if applicable)
-
Consent / acceptance - if the module requires explicit consent (for example, yield product terms), the user confirms it
-
Entitlements are issued by the Core layer - the module receives rights: which API can be used, which limits apply, which operations are allowed
-
UI is exposed only for the active module - screens, routes, and components are added - the user sees only what they have enabled
-
Event subscription - the module subscribes to the required events (statuses, balance changes, risk decisions) and operates in real-time
6.4. How a module is structured technically (Module Package)
Each module has a packaged structure and a manifest:
module_id,version(SemVer)required_core_version(compatibility)permissions(access to data domains)entitlements(which rights are granted)api_contracts(OpenAPI)event_contracts(which events it publishes/consumes)policy_bundle(limits/rules/access)observability(metrics, SLOs, alerts)kill_switch(instant disablement if required)
This ensures manageability and fast, independent releases.
6.5. Isolation of modules: security, stability, fast rollback
To ensure that modularity is safe and does not turn into chaos:
-
Contract-based isolation - a module interacts with the Core via API and events, not through direct access to the core internals
-
Policy-as-code and entitlements - a module cannot obtain more permissions than allowed by policies. Limits and access rules are defined declaratively
-
Operational isolation - each module has:
- its own metrics and SLO
- its own alerts
- the ability to be limited to a user cohort
- fast rollback or disablement
6.6. Why modularity is the key to product and IT scalability
A modular system addresses three classes of problems identified in the research at once:
- weak UX → “show only what is needed”, the interface is not overloaded
- outdated monolithic IT landscape → new functionality lives independently and does not break the core
- low speed of innovation delivery → releases and experiments are possible at the module level, without stopping the platform
7. Real-time mechanics: event-driven instead of batch
Events as the nervous system of the platform: instant statuses, full traceability, and real-time consistency across all channels.
7.1. Event model (events as the “nervous system” of the platform)
We build the platform so that any significant action is recorded not only as a database entry, but also as an event that other components and modules can react to. This is the foundation of real-time behavior and cross-channel consistency.
Base categories of events:
-
Account & Identity events - login/logout, new device, changes to security settings, KYC status change
-
Ledger events - balance change, posting, reservation, debit/credit
-
Payment lifecycle events - operation created → accepted → risk check → sent → confirmed → completed/rejected
-
Risk & compliance events - risk decision (allow/step-up/hold/deny), rule trigger, limit change
-
Notification events - an event that must be reflected in a notification/event center
-
Module events - events of modules (staking, P2P, RWA, B2B approvals, etc.) on top of platform-level ones
Info
Why this matters: in legacy systems, status “lives” inside separate subsystems and is updated in batches. In our case, status is a sequence of events, equally available to the mobile app, web, support, and back office.
7.2. Why this matters for mobile UX (real impact for the user)
The event-driven model directly translates into strong mobile banking:
-
Instant operation statuses - the user sees what is happening: “created → check → sent → confirmed”. This reduces anxiety and lowers the load on support
-
Clear reason and next step - if an operation is held or requires confirmation, the event carries the reason/reason class (for example, “step-up confirmation required”) and the UI shows a concrete action
-
Unified history and no desynchronization - the transaction history is the same across all channels because it is built on a single event sequence. There is no situation where “the app shows one thing and the operator sees another”
-
Reactive notifications - notifications and the event center become a continuation of statuses: the user receives a notification not “when it was possible”, but when the event actually occurred
7.3. Why this matters for business and compliance (transparency and controllability)
For business and compliance, an event-driven architecture provides what legacy systems usually cannot:
-
Full traceability - we can reconstruct the entire chain: who initiated the action, which check was triggered, what decision the risk engine made, and at which stage the operation was delayed
-
Fewer manual investigations and “operational admin work” - problems become visible immediately: there are events, metrics for each stage, and alerts for degradation
-
Easier reporting and monitoring - reports and analytics are built on the event stream, not on “end of day” data dumps. This is important both for financial analytics and for risk monitoring
7.4. How this is implemented technically (no “magic”, but understandable)
Example
To make the event model work reliably, we design in:
- unified event contracts (schemas, versions, compatibility)
- guaranteed delivery (at-least-once, with deduplication on the consumer side)
- ordering within a stream (events of a single operation/account are delivered in order)
- event versioning (old versions are processed, new fields are ignored)
- stream observability (metrics for latency, loss, and processing)
This is not “just Kafka”, it is a managed event system that guarantees consistency and reliability.
8. Durable workflows: how we build “non-breakable” processes
Long-running workflows that survive failures: payments, approvals, asynchronous operations with guaranteed delivery.
Warning
In legacy systems, long-running operations are often “lost” during failures. We build durable workflows - processes that survive outages and guarantee completion.
Examples:
- Payments - from creation to final status, with retries and idempotency
- Approvals - approvals that wait for decisions but do not “hang”
- Asynchronous operations - integrations that run in the background but remain visible to the user
- Risk checks - long-running checks (KYC, AML) that do not block the interface
We use state machines + event sourcing to:
- restore state after a failure
- avoid duplicates and data loss
- provide full process visibility to the user and the operations team
9. API-first and contract-driven design
Formalized API and event contracts: synchronous and asynchronous interfaces, versioning, compatibility, and partner integrations.
9.1. Why API-first is the foundation of modularity
Info
The API-first approach means that we define contracts first and then implement them. This provides:
- clarity on how components interact
- the ability to develop in parallel (frontend and backend)
- stability as the system evolves
- a foundation for partner integrations
In legacy systems, it is usually the opposite: code is written first, and then it is “somehow” integrated. The result is chaos and a high cost of change.
9.2. Two types of contracts
We enforce contract-driven design at two levels:
9.2.1. API Contracts (synchronous)
Used where an immediate response is required:
- login/session
- balance inquiry
- operation creation
- status inquiry
- management of modules and settings
9.2.2. Event Contracts (asynchronous)
Used for real-time behavior and loose coupling:
- operation status updates
- risk decisions
- notifications
- module events
Tip
Why this matters: without event contracts, an event-driven architecture turns into a “zoo” where everyone publishes whatever they want. We fix event schemas, versions, and compatibility from the start.
9.3. Versioning of API and events (how we avoid “breaking releases”)
We design for managed evolution:
-
SemVer logic
- minor changes are backward-compatible
- major changes only through a new version and a migration period
-
“Extend, do not break” strategy
- add new fields without removing old ones
- errors and statuses have stable codes
-
Deprecation policy
- deprecation announcement
- support period
- telemetry of old version usage
- planned shutdown only after migration
9.4. How this supports modularity and release velocity
Contracts are the foundation that allows modules to be truly independent:
- a module can evolve and be released separately as long as it complies with the core contract
- the core can evolve without breaking a module as long as compatibility is preserved
- new modules can be plugged in quickly because the platform “entry points” are formalized
As a result, we get what is almost absent in legacy systems:
- fast releases
- predictable integrations
- fewer regressions
- the ability to grow a partner ecosystem
9.5. Partner integrations and B2B API (how we do it “the right way”)
For businesses and partners, we design interfaces so that they are:
- clear
- secure
- reproducible
What matters:
- key and access management through policies and roles
- webhooks and events for real-time integration
- rights limitation at the entitlements level
- audit of all integration actions
This makes integrations a part of the platform, not a set of unique “manual connections” that are rebuilt from scratch every time.
10. Security-by-design (multi-layer security)
Security is built into the platform: authentication, risk engine, policy-as-code, audit, and compliance as core invariants.
10.1. Principle: security is built into the platform, not “bolted on later”
We design security as a set of core invariants of the Core. This means:
- any module operates only within permitted scopes and policies
- critical operations always pass through a unified risk/security layer
- all actions and decisions are traceable and auditable
This is how we avoid the typical legacy problem where security becomes a “layer of rules on top of chaos” and starts blocking the product instead of protecting it.
10.2. Authentication and access: strong security without friction
Our goal is high security with minimal friction in UX.
10.2.1. Device and session as a trust factor
- trusted device binding
- new device control
- notifications and confirmations for suspicious logins
10.2.2. Step-up confirmations
We do not force users to confirm everything in the same way. We use step-up:
- routine actions pass quickly
- suspicious actions require stronger confirmation (MFA/passkeys/biometrics)
10.2.3. Passkeys / phishing-resistant approach
Where applicable, we use a passkeys approach as a phishing-resistant method for authentication and confirmations. This provides:
- lower risk of password compromise
- faster login
- higher trust in the product
10.3. Risk Engine: allow / step-up / hold / deny decisions
Instead of static “allow/deny”, we build risk decisioning that operates in real time and manages risk flexibly.
10.3.1. Types of decisions
- allow - allow through
- step-up - require stronger confirmation
- hold - hold pending review or additional conditions
- deny - reject
10.3.2. What we consider in signals
- new device, geography, travel velocity
- behavioral patterns
- amount/frequency anomalies
- counterparty/rail/network
- KYC status and history
10.3.3. Why this matters
This approach allows us to simultaneously:
- reduce fraud and losses
- avoid breaking UX with mass “unnecessary confirmations”
- provide transparency for compliance
10.4. Policies as code (Policy-as-code): centralized access and limits
Note
One of the main legacy problems is that rules are “smeared” across code, which makes them:
- non-auditable
- hard to change
- unpredictable
We move rules into a declarative layer (policy-as-code) so that:
- access and limits are unified for all modules
- rule changes can be managed in a controlled way
- compliance and audit can see “what exactly is allowed and why”
What we define via policies:
- access to data domains
- limits by roles, countries, KYC levels
- conditions on operations (for example, step-up under certain parameters)
- compliance rules and sanctions screening
10.5. Immutable audit: full traceability of critical actions
All critical actions are recorded in an immutable audit trail:
- who (user/role/system)
- what (action, parameters)
- when (timestamp)
- result (success/error, risk engine decision)
- why (which rules/policies were applied)
This provides:
- full visibility for compliance
- the ability to investigate incidents
- evidence of regulatory compliance
10.6. Integration with KYC/AML providers
We integrate checks as part of the platform:
- checks during registration and KYC level upgrades
- periodic re-checks
- sanctions lists and PEP screening
- signals for the risk engine
11. Reliability & Observability (стабильность как стандарт)
Наблюдаемость платформы: метрики, трейсы, логи, SLO, алерты и incident management как часть продукта.
11.1. Почему observability - это не “опциональная” часть
Example
В legacy-системах часто “что-то сломалось”, но никто не знает что и где. Мы строим observability как часть архитектуры:
- метрики - что происходит в реальном времени
- трейсы - как запрос проходит через систему
- логи - детали для расследования
- SLO - обещания пользователям и командам
- алерты - уведомления о проблемах
Это даёт:
- быстрое обнаружение проблем
- быстрое восстановление
- понимание причин
- данные для улучшения
11.2. Метрики и SLO
Мы отслеживаем метрики по ключевым операциям:
| Операция | Метрики | SLO |
|---|---|---|
| Логин | latency, success rate, errors | 99.9% success, <500ms p99 |
| Платёж | latency, success rate, fraud rate | 99.95% success, <2s p99 |
| Запрос баланса | latency, cache hit rate | 99.99% success, <100ms p99 |
| Риск-решение | latency, decision distribution | <100ms p99 |
Метрики публикуются в dashboard и используются для алертов.
11.3. Трейсинг и логирование
Каждый запрос имеет trace ID, который позволяет отследить его путь:
- от клиента через API-gateway
- через Core-сервисы
- через модули
- до внешних интеграций
Логи структурированы и содержат контекст (trace ID, user ID, operation ID), что упрощает поиск проблем.
11.4. Incident Management и On-call
Мы строим процесс:
- Detection - алерт срабатывает при нарушении SLO
- Escalation - уведомление on-call инженера
- Investigation - быстрый поиск причины через метрики/трейсы/логи
- Mitigation - быстрое восстановление (откат, отключение модуля, масштабирование)
- Resolution - постоянное исправление
- Postmortem - анализ и улучшения
12. Technology stack
Technology choices: languages, frameworks, databases, queues, and tools that support the architecture.
Info
The technology stack is not about “fashion” - it is a tool that must support architectural principles:
- contract-based design (API-first)
- event-driven processing
- scalability and observability
- fast independent releases
Key components:
- Languages: Go/Rust for Core (speed, reliability), TypeScript for modules and UI (ecosystem, development speed)
- Frameworks: gRPC/HTTP for API, Kafka/RabbitMQ for events
- Databases: PostgreSQL for transactional consistency and audit, Redis for cache and sessions
- Orchestration: Kubernetes for scaling and management
- Observability: Prometheus/Grafana for metrics, Jaeger for traces, ELK for logs
13. UI/UX and team
Design system, component-based approach, UX metrics, and team organization for rapid development.
13.1. Design system as the foundation
Tip
We build a design system, not just “mockups”:
- unified components (buttons, forms, statuses, errors)
- unified patterns (how we show operations, how we explain errors, how we confirm actions)
- unified principles (speed, transparency, control)
This allows us to:
- quickly add new screens (components already exist)
- ensure consistency (users recognize the interface)
- scale teams (new developers onboard quickly)
13.2. UX metrics and focus on outcomes
We do not rely on “like or dislike”. We measure:
- scenario speed - how long transfers, exchanges, and module activation take
- drop-off - where users abandon a process
- errors - which errors occur and how often
- NPS/CSAT - satisfaction with key operations
These metrics feed our prioritization and improvement decisions.
Note
Why this matters: in legacy banks, a “beautiful design” often does not solve real problems. We focus on what actually impacts users.
13.3. UX for B2C and B2B: different products within a single platform
We design two modes from the start - for private users and for businesses - so that B2B is not an “accidental add-on”.
13.3.1. B2C (individual users)
- maximum speed in key scenarios: transfers, exchanges, security control
- transparent statuses and clear reasons
- personalized assembly of modules: users enable only what they need (Earn, P2P, advanced reports, etc.)
13.3.2. B2B (companies)
- roles and permissions, limits by role/department
- approvals (four-eyes), action logs, exports, and reporting
- convenient mass operations, integrations, web management console
- modularity at the company level: a business connects only what matches its processes
14. How this addresses the problems identified in the research
Solution matrix: how each platform component resolves specific mobile banking and legacy IT problems.
14.1. Matrix “problem → solution mechanism → where implemented”
| Problem from the research | Solution mechanism | Where implemented |
|---|---|---|
| Weak UX, overloaded application | Modular UX: the base interface remains lightweight, extensions are connected selectively | Experience Layer + Module Marketplace + Entitlements |
| No sense of real-time, statuses “live their own life” | Event-driven statuses + a unified operation state machine | Payments Orchestrator + Event Backbone |
| Long / fragile processes (KYC, withdrawals, approvals) | Durable workflows with state persistence, retries, and compensations | Workflow Engine + Core |
| Legacy core makes changes expensive and risky | Core + Modules: the core is stable, new functionality is added via contract-based modules | Core Platform + Modules Layer |
| Integrations are “unique” every time and break when things change | API-first + contract-based design (OpenAPI + event contracts), versioning | API Layer + Contracts + CI/CD |
| Security “chases the product” and hurts UX | Security-by-design + step-up + risk decisioning | Identity & Access + Risk Core |
| Limit and access rules are scattered across code | Policy-as-code: declarative policies, centralized control | Policy Engine + Entitlements |
| Weak observability: problems are discovered from users | Observability standard: traces / metrics / logs + SLO / alerts | Observability Core |
| Feature growth leads to chaos and rising support costs | Isolation of modules: SLO, kill-switch, canary, rollback | Module Ops + Feature Flags |
| Business users are uncomfortable: roles, approvals, control | B2B modules: roles, approvals, limits, mass operations | Business Modules + Core |
14.2. What this gives the platform (in outcome terms)
-
Development speed
We can add new directions via modules without rewriting the core and without creating a “release queue”
-
Reliability and manageability
Operations have a transparent lifecycle, processes are resilient through workflows, and operations are controlled through observability and SLO
-
A strong mobile product without overload
The UI remains clear because functionality is revealed through modularity - the user connects only what is needed
-
Security that does not kill UX
The risk engine and step-up confirmations allow stronger control only where it is actually needed
-
Readiness for scaling
Architectural layers, contracts, isolation of modules, and a cloud-native approach allow predictable scaling of load, teams, and functionality
14.3. Why this approach is future-proof (technologies change - the platform remains)
Question
How do you build a system that will remain relevant as technologies, markets, and requirements change?
We start from the assumption that:
- new rails, networks, and providers will emerge
- compliance requirements will change
- user behavior and expectations of UX will evolve
Therefore, we design the system so that changes happen:
- through contracts (API + events)
- through modules (adding or replacing functional blocks)
- without breaking the Core (the core remains stable)
- with controlled releases (canary, flags, rollback, SLO)
This allows us to quickly introduce new capabilities while preserving the stability of the platform - a key difference from legacy IT, where innovation always conflicts with stability.
Conclusion
We are building a next-generation banking platform that solves the problems of weak mobile banking and outdated IT systems not through “cosmetic improvements”, but through architecture.
Key ideas:
- Core + Modules - a stable foundation that does not break as it expands
- Real-time - events and streams instead of batch processing
- Contract-based design - API-first and managed integrations
- Security built in - not “bolted on later”, but part of the architecture
- Observability as a standard - we see problems and recover quickly
- Scalability - layers, contracts, and isolation enable predictable growth
The result is a mobile bank that is fast, reliable, secure, and ready for the future.