Developing a portal for a bank: where the logic breaks
A bank portal breaks not at the storefront, but at the joints. The customer account looks ready while operations run in a single loop: form, data validation, response.
As soon as an integration with the bank core appears between the interface and the accounting system, what is invisible in a demo comes out — data desynchronization, duplicate debits, stuck requests.
A typical failure looks like this: the client sends a payment, the core processes it, and the portal, due to a timeout, considers the operation unsuccessful and offers to retry. The second request goes without an idempotency key, and the statement shows two identical debits.
The reverse situation is no easier: the balance in the account is read from a replica that lags by minutes, and the client sees an amount that no longer exists. Incident analysis goes to manual reconciliation of registers — hours of support work and lost trust.
Peak load finishes it off with the same mechanism. On payout days and during mass payments, queues between environments grow faster than the core can process them, and a portal without predictable degradation starts responding with timeouts to everything — including login.
Operations get stuck in an intermediate status, and neither the bank nor the client understands how they ended.
These three points — data desynchronization, behavior under peak load, and operations without an unambiguous final status — determine whether the portal can withstand real operation. Next we analyze how this is closed in bank portal development.
What changes after implementation: effect in numbers
The effect of a portal is measured by operational metrics, not a demo scenario.
Response time for typical operations — payment, transfer, product application — is reduced from minutes to fractions of a second: the request goes directly to core services, without intermediate exports and manual queues.
The share of automatic scenarios grows because checks, risk assessment, and signing are assembled into a single route.
Where an operator previously reconciled data by hand, the rule works on its own: the system matches statements, registers, and statuses, and a human connects only to discrepancies.
The volume of manual reconciliations drops by a factor — for mass operations usually by an order of magnitude.
The number of incidents on integrations decreases when exchange with the core, payment services, and external systems gets retries and duplicate protection.
Failures stop accumulating unnoticed and are analyzed via the log: you can see which request, at what moment, and why it failed.
Service availability stays at a level where planned updates do not stop work: releases are rolled out gradually, rollback takes minutes.
Additionally, the environment is designed to PCI DSS requirements — this removes part of the manual evidence during an audit and eliminates the risk of blocking findings.
The result — predictable load on the operations unit: fewer manual actions, less downtime, measurable response at every step of customer service.
Three approaches: ready platform, build from scratch, hybrid
The choice between a ready banking platform, a build from scratch, and a hybrid is dictated by the product profile: how many integrations with ABS, processing, and external services need to be covered, what load reserve is laid for peak hours, and how unique the user scenarios are.
A platform of FLEXTERA level gives a quick start and a proven data model, but non-standard logic hits the vendor core limits.
A build from scratch removes these limits: we control the data model, integration scheme, and load profile — at the cost of a later first release. A hybrid takes typical blocks from the platform, and moves client scenarios and calculation logic into separate services.
| Option | When suitable | Limitations |
|---|---|---|
| Ready banking platform | Quick launch of a typical line: accounts, payments, cards, customer account | Depth of customization limited by vendor, non-standard logic moved to external services |
| Build from scratch | Unique products and scenarios, strict load reserve | Later first release; team covers the entire stack — from interfaces to integrations |
| Hybrid approach | Typical core already exists, but some scenarios are unique | More complex architecture; discipline needed for contracts between modules |
In practice the choice comes down to the share of non-standard logic over a two-three year horizon: the higher it is, the more noticeably hybrid wins in implementation time and support effort.
How the project goes: stages of engineering work
The order of work is set by dependencies, not schedule convenience: until the system interaction scheme is described, building environments is pointless — a fix in integration invalidates checks already done. Therefore stages go sequentially, with a recorded result at each step.
- Survey and integration audit. We inventory the accounting system, payment processing, and external services: what data flows exist now, where operations are done manually, what will become a bottleneck as customer numbers grow.
- System interaction scheme. For each interface we fix the exchange protocol, message format, timeouts, retry on failure, and reconciliation order. Separately — idempotency: resending a request must not create a duplicate payment.
- Environment assembly. We raise isolated environments for development, testing, and pre-production acceptance: anonymized data, schema migration versioning — so release rollback does not require manual database recovery.
- Security and access. We describe roles from job scenarios: who sees, who confirms, who only reads. We configure the employee action log, session restrictions, and channel encryption.
- Load checks. We run peak scenarios: mass login to the customer account, payment batch, statement export. We look at response time, behavior on node failure, and recovery after load removal.
- Acceptance and handover to support. We check end-to-end paths — account opening, payment, support request — with the expected result at each step. We hand over operating procedures, monitoring panels with alerts, release rollback procedure, and the known limitations log.
What the customer receives: delivery package
We fix the delivery package at acceptance: each artifact has an owner on the bank side, and it is transferred to your infrastructure — not left available only to us. Below is the list we use to verify handover; if an item is missing, the work is not considered closed.
- Source code in your repository: full change history, release branches, and a build pipeline that reproduces on your machines without our involvement.
- Integration schemes: exchange diagrams with accounting systems, the bus, and external services, with message formats, retry order, and described behavior when the counterparty is unavailable.
- Access policies: roles, permission matrix, strong authentication rules, and action logging — with rationale for why a role has exactly that set.
- Support procedures: change release windows, rollback procedure, criteria for calling the on-call shift, and responsibility distribution during an incident.
- Instructions for the support line: typical request scenarios, diagnostic queries, and escalation procedure — the first line closes some requests without reaching developers.
- Environment documentation: stand configurations, list of external dependencies, backup scheme, and tested recovery scenario.
- Check reports: load test results, vulnerability scanning, and the share of critical paths covered by automated tests.
Separately we hand over the known limitations log: what consciously was not included in scope, which places require attention during further work, and where load reserve is laid. This saves months for a new team analyzing someone else's code.
Case: how we relieved branches
A bank with a branch network in several regions started with a typical task: the portal should remove routine operations from employees.
Before implementation, the customer account worked as a storefront — you could view products, but to issue a card or certificate only at a branch. During peak hours queues grew in the halls, and up to half of requests were about one question: application status.
Where the bottleneck turned out to be
The portal synchronously waited for a credit core response to every request, and pulled statuses directly from the operational database. Any core delay stopped both the account and branch work — the failure was shared.
We separated flows: the application goes to a queue and is processed by events, statuses are read from a separate data model, resending is protected from duplicates, and cache holds reference data and statements.
The transition was done in stages, with feature toggles and quick rollback: first certificates and statements, then card applications, last — credit products.
Numbers were taken from monitoring panels on Grafana and verified against contact center exports — each metric confirmed, not taken from the contractor's report.
Three months after launch: most applications close online without an operator, processing reduced from 25 minutes at a branch to 8 minutes in the account, status calls fell almost threefold, and peak load grew by a factor without response degradation. Branches focused on consultations and complex products instead of printing certificates.
How does a self-service storefront differ from a portal?
A self-service storefront is a limited environment: several scenarios, a fixed product set, and one entry channel. It shows terms, accepts an application, and delivers a ready product.
Solution boundaries are set in advance, so scope here is predictable, and launch fits into one cycle.
A customer portal is an environment where the same scenarios live together with identification, profile, operation history, and access separation.
Customer, employee, and partner roles are added, along with an action log, integrations with accounting systems, and parallel support of several products.
Hence requirements the storefront does not have: end-to-end authorization, data disclosure consents, and exports for internal services.
The difference is visible in scope. For a storefront it is customer scenarios and one or two interfaces to internal systems. For a portal — customer data model, single entry point, integration layer, and access rules permeating all sections.
If you lay only a storefront, after several iterations you hit the ceiling: each new requirement is attached on the side rather than extending the foundation.
The criterion for the solution boundary is how many scenarios must share common state. While there are two-three products and they are unrelated, a storefront is justified.
As soon as a shared profile, history, roles, and end-to-end authorization appear, building a portal at once is cheaper than moving logic later.
When estimating scope, we start with the scenario map and integration points: it shows where in your case the storefront ends and the portal begins, and which blocks should not be built prematurely.
Technical questions asked before start
Five questions usually come up before the work plan is signed: they are asked by the security service, operations, and architecture. The answers determine decisions that are later expensive to change — the access separation scheme, behavior during failures, and load profile. Therefore we address them before start, not at the acceptance stage.
How will the security service be sure access is restricted?
We show the data flow scheme: where personal and payment data is stored, which services access it, and what each administrator sees.
We separate roles by the least privilege principle, enable logging of access to sensitive fields, and conduct development and load checks on anonymized data.
What happens if an external service is unavailable?
Critical scenarios must not depend on a single provider. We lay in retries with increasing delay, queues for unprocessed operations, reference data cache, and idempotency so a retry does not create a duplicate payment. For operations that cannot be postponed, we provide a manual mode with clear procedures.
How is readiness for load confirmed?
We build a behavior model based on the request profile: share of reads and writes, peak hours, spikes on payout days. We run stepwise load growth and look at 95th percentile response time, not average — average masks failures. The output is a report with failure points and capacity reserve.
Who is responsible for operation after handover?
Handover is not only access, but also documentation, schemes, instructions for typical incidents, and failure analysis on the test environment.
We fix the warranty period, escalation procedure, and response time for requests of different classes, so the client team can close most of them themselves.
How difficult is it to add a new product?
We separate the portal core from product modules: product card, application rules, calculations, and documents live in their own configuration.
A new product is connected by configuration and a separate module, without changing common scenarios — this reduces the risk of affecting working processes when expanding the line.
Let's discuss the task and come back with a work plan
To make the first review substantive rather than overview, a description of the process the portal must cover is enough.
Describe the task in free form — we will clarify details on a call and come back with a work plan where stages, team composition, and timelines are tied to specific results.
- Which operations the portal covers: applications, payments, servicing, documents — and what is critical in the first iteration.
- Which systems require integration: core, processing, login and access rights, external services — and whether there is a test environment.
- Requirements for placement and data protection: whose environment, what approvals, whether there is a ready list of requirements from the security service.
- Expected load: number of users, peak periods, operation volume — architecture and capacity reserve depend on this.
- What is already ready: design, prototypes, description of exchange interfaces, collected requirements — so we do not do work twice.
- Who on the bank side makes decisions on disputed points and how quickly approval passes.
Based on this set, we come back with a timeline estimate, team composition, and phased work plan: what we do in the first iteration, and what we move further.
The next step is a substantive call, after which you have scope, work order, and the point of connection for our engineers.
