Retail banking solutions are the connected systems that let individuals open and manage accounts, move money, use cards, borrow, receive support, and complete regulated identity checks across mobile, web, branch, contact-centre, and partner channels. The visible application is only the edge. Reliable service depends on identity, customer records, product configuration, payments, fraud controls, ledgers, documents, notifications, audit evidence, and round-the-clock operations working as one system.
This FAQ explains the architecture and delivery decisions behind modern retail banking software. It is intended for business, product, risk, operations, and engineering teams evaluating a new channel, a core-integration layer, or a staged modernization. For broader integration and workflow work, see Edilec's enterprise systems service and cybersecurity service.
What does a retail banking solution include?
Scope should be expressed as customer journeys and critical operations, not a list of screens. Account opening, login, balance and transaction viewing, beneficiary management, transfers, card controls, statements, disputes, and service requests each cross several systems. A solution may provide a complete digital channel or only a domain component such as onboarding, payment orchestration, case management, or customer communication.
| Capability | Primary responsibility | Common system of record | Critical control |
|---|---|---|---|
| Customer onboarding | Collect application, verify identity, capture consent, open product | Customer, identity, and core banking platforms | Identity proofing, sanctions or policy checks, decision evidence |
| Account servicing | Present balances, transactions, statements, and preferences | Core banking and document systems | Authorization, freshness, reconciliation |
| Payments and transfers | Validate, authorize, route, post, and report money movement | Payment hub, ledger, core banking | Limits, fraud checks, idempotency, settlement status |
| Cards | Issue and manage cards, controls, tokenization, disputes | Card processor and case platform | Strong authentication, status synchronization, PCI scope |
| Support and complaints | Identify the customer, manage a case, resolve and evidence outcome | CRM and case management | Privacy, maker-checker controls, retention, escalation |
A good scope names the owner and service level for every handoff. If a mobile app says a transfer succeeded while the payment hub remains uncertain, the customer experience and ledger state diverge. The design therefore needs explicit pending, failed, reversed, and timed-out states rather than a binary success message.
How should the architecture be organized?
A durable design separates channels from business orchestration and systems of record. Mobile and web clients should not embed core-specific rules or call sensitive back-end functions directly. An API and orchestration layer authenticates the caller, enforces policy, coordinates systems, normalizes errors, and returns a stable contract. Domain services can then evolve without forcing every channel to understand legacy interfaces.
Event-driven integration is useful for notifications, downstream reporting, fraud signals, and long-running processes, but it does not remove the need for transaction boundaries. Money movement requires idempotency keys, ordering rules, reconciliation, and a source of truth for final state. Events should carry immutable identifiers and versioned schemas, with a documented replay policy.
| Layer | What belongs there | Design question | Operational evidence |
|---|---|---|---|
| Channels | Mobile, web, branch and assisted-service interfaces | Can every state and failure be explained to the customer? | Journey monitoring and accessibility tests |
| Identity and access | Authentication, device and session controls, authorization | Is access decided consistently for customers and staff? | Authentication events and access decisions |
| Orchestration and APIs | Journey state, policy, integration and error normalization | Can retries occur without duplicate financial effects? | Trace, idempotency record and API inventory |
| Systems of record | Customer, account, loan, card, payment and ledger platforms | Which system owns each fact and transition? | Reconciliation and ownership map |
| Operations and control | Fraud, monitoring, case management, audit and resilience | Can the bank detect, contain and recover within tolerance? | Alerts, tests, incidents and recovery results |
How should identity, security and privacy be designed?
Security starts with the journey and data classification. Customer authentication, staff access, service identities, privileged administration, and partner APIs have different threat models. Authorization must be checked for the requested function and object, not inferred from a successful login. OWASP's API Security Project highlights object-level and function-level authorization because APIs often expose sensitive records and business operations.
Reduce payment-data exposure by using processor-hosted components or tokenization where appropriate, and map the resulting environment against the current PCI DSS scope. Encrypt data in transit and at rest, manage keys separately, mask sensitive values in logs, and set retention by purpose. Fraud controls should be explainable to operations and have a review path; a model score alone is not a final customer decision.
- Use step-up authentication for material changes and high-risk transactions.
- Apply least privilege to customer-service and operational roles, including field-level restrictions.
- Separate production administration from everyday business access and record privileged actions.
- Threat-model account recovery, beneficiary changes, payment limits, device enrollment, and support impersonation.
- Test accessible authentication and error handling across supported devices and assistive technologies.
What does operational resilience require?
Availability is only one dimension. The Basel Committee defines operational resilience around the ability to deliver critical operations through disruption. Its operational resilience principles cover governance, dependency mapping, business continuity, incident management, third-party dependencies, and resilient ICT. Translate that into a map from customer service to people, applications, data, infrastructure, facilities, and suppliers.
Set an impact tolerance for each critical operation and test realistic failure modes: an identity provider outage, delayed ledger updates, a payment-processor timeout, corrupted configuration, loss of a cloud region, or an unavailable vendor. Degraded service should be designed, not improvised. Customers may need read-only access, delayed processing with a clear status, or an assisted route with controlled limits.
Third-party contracts do not transfer accountability. Maintain service dependencies, concentration risks, data locations, exit plans, recovery commitments, and test evidence. The current Basel ORR20 chapter specifically links third-party management and resilient ICT to the delivery of critical operations.
Should a bank replace the core or modernize around it?
There is no universal answer. A stable core with constrained product capability may support a channel and orchestration modernization first. A core that cannot meet product, resilience, data, or operating requirements may justify replacement. The decision should compare business outcomes, migration risk, data quality, integration complexity, vendor constraints, operational readiness, and the cost of running two estates during transition.
Avoid a front-end-only modernization that reproduces broken processes behind a polished interface. First define canonical customer, account, product, and transaction contracts. Introduce an anti-corruption layer around legacy interfaces, reconcile old and new states, and migrate by journey or product cohort. Dual running needs explicit ownership, not an indefinite promise to keep both systems synchronized.
What should a delivery plan contain?
The first phase should produce a journey map, architecture and data contracts, control requirements, dependency inventory, migration approach, operational model, and measurable release slice. A useful slice is complete enough to operate: for example, viewing balances and transactions for one product cohort with real identity, monitoring, support, and reconciliation. A collection of disconnected prototypes does not prove the operating model.
| Phase | Primary output | Exit evidence |
|---|---|---|
| Discovery | Prioritized journeys, critical-operation map, current constraints | Approved scope, owners, risks and success measures |
| Foundation | Identity, API standards, environments, observability, security controls | Threat model, tested pipeline, operational dashboards |
| Journey release | One end-to-end capability for a controlled cohort | Functional, security, resilience and reconciliation results |
| Migration | Data and customer cohorts moved with rollback and support | Reconciled records, exception closure, adoption measures |
| Scale and operate | More journeys plus durable service ownership | Service levels, incident learning, cost and outcome trends |
How should value and quality be measured?
Measure complete customer outcomes: successful onboarding, authenticated-session completion, payment success and finality, time to resolve disputes, first-contact resolution, accessibility defects, fraud loss, reconciliation breaks, and recovery performance. Technical measures such as latency and error rate remain necessary, but they should be connected to the affected journey and product.
Review false declines, abandoned flows, manual exceptions, and complaints by cohort. An automation that lowers handling time but creates more unresolved cases is not an improvement. Use the NIST Cybersecurity Framework 2.0 to organize cybersecurity outcomes while retaining banking-specific risk, compliance, and resilience obligations.
Key takeaways
- Scope retail banking software by customer journey and critical operation.
- Keep channels separate from domain orchestration and systems of record.
- Design uncertain, reversed, and degraded states explicitly.
- Enforce authorization at function and record level, not only at login.
- Map third-party and technology dependencies to impact tolerances.
- Migrate in controlled cohorts with reconciliation, rollback, and support evidence.
Frequently asked questions
How long does a retail banking solution take to implement?
A bounded journey can reach a controlled release in months, while a multi-product core transformation is a multi-year program. The meaningful estimate follows discovery of systems, data, controls, suppliers, migration cohorts, and operational readiness. Treat estimates made before that work as ranges with assumptions.
Should the bank buy a platform or build custom software?
Buy standardized capabilities where a product fits control, integration, localization, and exit requirements. Build differentiating journeys and orchestration where the bank needs unique policy or customer experience. Most programs are hybrid; the architecture must make ownership and upgrade boundaries clear.
Can retail banking workloads run in public cloud?
They can where regulation, risk appetite, data requirements, resilience design, and supplier governance permit. Cloud use does not remove the bank's responsibility for identity, configuration, data, application behavior, recovery, and third-party oversight.
Procurement should require more than a feature demonstration. Ask vendors to show API contracts, identity integration, deployment responsibility, recovery evidence, accessibility, data export, audit capabilities, support escalation, release practices, and exit arrangements. Test representative journeys using realistic failure states. A platform that cannot explain pending transactions, reconcile duplicate events, or support a controlled rollback will transfer hidden work to bank operations regardless of how quickly its standard screens can be configured.
Conclusion
Professional retail banking delivery connects customer journeys to authoritative records, explicit controls, and tested operations. The strongest solution is not the one with the most features; it is the one that preserves financial state, protects customer access, explains failures, withstands disruption, and can be changed without losing control of the service.