Internet Banking App Development

Internet banking system development sits at the intersection of front-end channel delivery and core banking integration. Unlike a standalone mobile app, an internet banking system is a full-stack platform that connects browsers, mobile apps, and third-party FinTech services to the account ledger, payment rails, and product catalogue that sit inside the bank's core infrastructure.

For engineering and product teams at established financial institutions, the challenge isn't building a banking portal from scratch. It's integrating a modern, PSD2-compliant digital channel layer onto a core banking system that may be running on Temenos T24, FIS Profile, or a mainframe batch-processing engine. Getting that integration right determines whether your internet banking platform performs at the level your customers and regulators expect.

Scrums.com provides dedicated engineering squads to banks and FinTech companies building or modernising internet banking platforms. Our teams have deep experience in channel integration architecture, open banking API compliance, and the security engineering that regulated financial services require.

Internet Banking System Architecture

A well-architected internet banking system separates concerns cleanly across three layers: the channel delivery layer, the API gateway, and the core banking integration. Each has distinct engineering requirements.

Channel Delivery Layer

The customer-facing web and mobile interface consumes banking APIs and renders account information, transaction histories, and payment workflows. Modern implementations use server-side rendering (Next.js) or single-page application frameworks (React, Angular) with WebSocket connections for real-time balance and notification updates. Responsive design across desktop, tablet, and mobile is table stakes; accessibility compliance (WCAG 2.1 AA) is increasingly a regulatory expectation in the UK and EU.

API Gateway and Banking API Layer

The API gateway authenticates sessions, enforces rate limits, routes requests to downstream services, and handles the OAuth 2.0/OIDC token lifecycle. PSD2 requires a dedicated TPP (Third Party Provider) interface for AIS and PIS; this cannot be the same interface used for direct customer access. Getting your API gateway topology wrong is expensive to fix once you're live and certified.

Core Banking Integration

The integration between your internet banking channel and the core ledger is where most internet banking programmes accumulate technical debt. Synchronous REST calls to a core banking system that was designed for batch processing create latency and brittleness. Event-driven integration patterns (core banking emitting domain events, channel subscribing via Kafka or IBM MQ) are more resilient and decouple channel release cycles from core banking release windows.

Session Security and Authentication

PSD2 Strong Customer Authentication (SCA) mandates two-factor authentication for account access and payment initiation. FIDO2/WebAuthn for passkey authentication, TOTP-based soft tokens, and SMS OTP all require different integration paths. Your SCA implementation also needs to handle step-up authentication gracefully for high-risk transactions without creating excessive friction for low-risk sessions.

Why This Matters for Legacy Bank Engineering Teams

Most digital transformation programmes at established banks stall not on the new channel code, but on the integration with the existing core. A neobank building on a modern cloud-native core has a fundamentally different engineering problem to a retail bank that processes end-of-day batch jobs on a 1990s mainframe.

The strangler fig approach works well here: build the new internet banking channel against a thin API abstraction layer that initially translates to legacy core calls. As the core modernises incrementally, the channel API layer stays stable. This means your internet banking platform ships to customers on a predictable schedule without being blocked by core banking migration timelines.

Our teams have delivered exactly this integration pattern for regulated financial institutions. Read about our approach to legacy modernisation and how it applies to channel integration programmes. For payment compliance specifically, our guide to compliant payment software delivery covers the PCI-DSS and PSD2 engineering decisions that affect internet banking platforms directly.

Internet banking platforms like these are built and delivered by dedicated teams through our mobile app development service.

Internet Banking Platform Types We Build

Different institution types need different internet banking architectures. Scrums.com engineering teams have built across five platform categories:

Retail Internet Banking Portal

Current account management, savings, personal loans, and card services via web and mobile. Real-time balance updates, push notification infrastructure, and P2P payment flows (Faster Payments, SEPA, Zelle). PSD2 SCA-compliant authentication with friction-right step-up for high-value payments. Key integration: Faster Payments and SEPA scheme APIs via Vocalink/EBA Clearing.

Business and SME Banking Platform

Multi-user access with role-based permissions (view-only, payment authoriser, account admin), bulk payment file upload (BACS, SEPA CT batch), and approval workflow engines. Commercial banking portals need to support multiple authorised signatories: a technical requirement that consumer internet banking platforms rarely have to solve.

Wealth and Private Banking Portal

Portfolio dashboards, investment order management, and relationship manager collaboration tools. Lower transaction volume but far higher data sensitivity and compliance requirements (MiFID II suitability documentation, KYC). Client-facing reporting that pulls from custody and portfolio management systems alongside the core banking ledger.

Open Banking and PSD2 Compliance Layer

Dedicated TPP-facing APIs for Account Information Services (AIS) and Payment Initiation Services (PIS). Consent management dashboards, eIDAS-certified QWAC/QSeal certificate infrastructure, and TPP onboarding/revocation workflows. The FCA and EBA have specific technical standards for PSD2 interfaces that require careful implementation and ongoing certification maintenance.

Digital Bank Migration

Migrating customers from a legacy internet banking platform to a new one without service disruption. Parallel-run phases, feature parity validation, and customer communication workflows. Our work on national payments compliance platforms and FinTech platform stabilisation covers the reliability engineering that makes these migrations safe.

Technology Stack for Internet Banking Development

Technology choices for internet banking platforms are constrained by security requirements, regulatory certification, and the need to integrate with existing banking infrastructure. The stacks our teams deploy:

Frontend

React and Angular for web portals; React Native and Flutter for companion mobile apps that share API client logic with the web. TypeScript throughout; type safety reduces the class of bugs that matter most in financial UIs (incorrect amounts, wrong account numbers, missing error states). Accessibility-first component libraries aligned to WCAG 2.1 AA.

API Gateway and Backend Services

Kong or AWS API Gateway for the TPP-facing and customer-facing API layers. Spring Boot (Java) or Kotlin for business logic services: the financial services ecosystem has the deepest library support for these runtimes (prowide-core for ISO 20022, jPOS for ISO 8583). Node.js for lightweight BFF (Backend for Frontend) services that aggregate and transform core banking responses for channel consumption.

Authentication and Security

Keycloak or ForgeRock for OAuth 2.0/OIDC identity infrastructure with PSD2 SCA extensions. FIDO2/WebAuthn passkey support for passwordless step-up. All secrets managed via HashiCorp Vault or AWS Secrets Manager, never in application configuration. TLS 1.3 enforced end-to-end with certificate pinning on mobile clients.

Infrastructure

AWS or Azure in multi-AZ active-active configuration. WAF rules tuned for financial services threat patterns (account enumeration, credential stuffing, session hijacking). DDoS mitigation via Cloudflare or AWS Shield Advanced; internet banking platforms are high-value targets. Explore the FinTech engineering capabilities our squads bring to these deployments.

Integration and Compliance Requirements

PSD2 and Open Banking

PSD2 requires banks to provide dedicated interfaces for TPPs by a specific regulatory deadline, with a fallback mechanism if the dedicated interface is unavailable. Building and maintaining these interfaces is an ongoing compliance obligation, not a one-time project. Your PSD2 API needs to pass the NCA (National Competent Authority) conformance testing, maintain uptime SLAs, and publish a public developer portal with technical documentation.

PCI-DSS Scope Management

Internet banking platforms that display card numbers, initiate card payments, or store card-related data fall within PCI-DSS scope. Careful CDE (Cardholder Data Environment) boundary definition (typically using iFrame-based card display from a certified third party rather than rendering card data in your own application) minimises scope and audit burden significantly. See our guide to PCI-DSS software delivery for the engineering detail.

Accessibility and Consumer Duty

The FCA Consumer Duty (UK) and equivalent EU regulations increasingly require digital banking services to be accessible to customers with vulnerabilities. WCAG 2.1 AA compliance, screen reader testing, and cognitive accessibility (clear error messages, timeout warnings, transaction confirmation flows) are now compliance considerations, not just UX nice-to-haves.

GDPR and Data Residency

Internet banking platforms process significant volumes of personal financial data. Data residency requirements (EU data staying in EU regions, UK data staying in UK regions post-Brexit) affect cloud region selection. Right to erasure requests require careful data mapping across the channel layer, API layer, and core banking audit logs. Explore how we approach dedicated team delivery for compliance-sensitive builds.

Frequently Asked Questions

How long does internet banking app development take?

A greenfield internet banking portal (account management, payments, statements) for a new digital bank typically takes 9 to 14 months. A new digital channel built on top of an existing core banking system takes 12 to 18 months, with the integration and parallel-run phases accounting for most of the timeline. Scrums.com teams mobilise within 21 days.

What's the difference between internet banking and mobile banking?

Internet banking traditionally refers to web browser-based access; mobile banking refers to native iOS/Android apps. In modern architecture, both consume the same banking API layer; the distinction is primarily in the channel delivery technology. Most banks build both simultaneously on a shared API foundation, with channel-specific UX patterns for each.

How do you handle PSD2 SCA compliance?

PSD2 SCA requires two independent authentication factors for account access and payment initiation. We implement SCA using FIDO2/WebAuthn for possession factors and TOTP or push notification OTP for knowledge factors. Transaction risk analysis (TRA) exemptions for low-value payments reduce step-up friction for routine transactions. The SCA implementation is integrated into the OAuth 2.0 authorisation flow, not bolted on as a separate layer.

Can you integrate with our existing core banking system?

Yes. We have experience integrating digital channel layers with Temenos T24/Transact, FIS Profile, Finastra Fusion, and bespoke mainframe cores. The integration approach depends on what your core exposes: REST APIs, ISO 20022 message queues, or SOAP services. We design the abstraction layer to shield your channel code from core banking implementation details, making future core migration or upgrade less disruptive.

What security certifications do your teams have experience with?

Our teams have worked on PCI-DSS QSA-assessed builds, SWIFT CSCF compliance implementations, ISO 27001-aligned development processes, and FCA/PRA-regulated system development. We treat security as a design constraint from day one, not a penetration test at the end of the project. See our FinTech engineering page for more context.