Build the digital banking experience that makes customers stay.

Customers do not evaluate your banking licence. They evaluate the 47 seconds it takes to make a payment on your app.

Traditional banks have strong balance sheets and poor digital products. Neobanks have excellent digital products and thin balance sheets. The digital banking channel is where the competitive battle is being fought — not in the core system, which is mostly invisible to customers. A digital banking platform that shows real-time balance updates, sends instant push notifications for every transaction, makes international payments in 30 seconds and surfaces spending insights without the customer asking is not a nice-to-have for incumbent banks facing neobank competition. It is table stakes. PROPELOO builds the digital channel layer — the web banking portal, mobile app, API banking and notification infrastructure — that transforms a banking licence into a banking product customers choose.

The digital banking platform stack.

The digital banking channel has distinct requirements across web, mobile, API and notification domains.

System Layers

• Digital Channel Layer: Web banking portal, mobile app, API banking for business customers, chatbot
• Authentication & Security Layer: MFA, biometrics, device binding, session management, fraud detection
• Transaction Layer: Payment initiation, beneficiary management, standing orders, direct debit management
• Account Services Layer: Balance display, transaction history, statement download, product management
• Notification & Engagement Layer: Push notifications, email alerts, spending insights, personalisation

Core Technical Capabilities

• Web Banking Portal

  Responsive web banking with account overview, transaction history with search/filter, payment initiation (domestic and international), beneficiary management, statement download, document centre and secure messaging.

• Mobile Banking App

  React Native app with biometric login, real-time balance and transaction feed, instant payment initiation, card management (freeze/unfreeze, PIN change), spending analytics and push notifications.

• Open Banking & PSD2

  PSD2-compliant AISP (account information) and PISP (payment initiation) APIs for third-party providers, OAuth 2.0 consent management, strong customer authentication (SCA) and developer portal.

• Notification Infrastructure

  Real-time push notifications for transactions (credit, debit, failed), payment confirmations, security alerts (new login, password change), balance thresholds and personalised spending insights.

• Core Banking Integration

  API adapter layer between digital channels and core banking system (Temenos, Finacle, Mambu, custom core) — abstracting core system complexity from digital channel development.

• Fraud & Security Layer

  Device fingerprinting for new login detection, behavioural biometrics for continuous authentication, transaction risk scoring, step-up authentication for high-risk operations and real-time fraud alerting.

How we think about digital banking.

The digital banking channel is not an interface to the core system. It is the product. The core system is the database. Design the product first.

• Real-time is the baseline expectation

  A customer who makes a payment expects to see it reflected in their balance immediately — not after a batch process runs. Push notifications for transactions must arrive within seconds — not minutes. A digital banking platform that shows yesterday's balance and notifies users hours after transactions have the UX of a 2005 internet banking portal. Real-time balance updates via WebSocket and sub-5-second push notifications are not features — they are the minimum viable digital banking experience in 2024.

  Axiom:

• Authentication must be strong and frictionless simultaneously

  PSD2 requires Strong Customer Authentication (two factors from something you know, have and are) for most payment operations. Biometric authentication (Face ID, fingerprint) satisfies both the "something you have" (phone) and "something you are" (biometric) factors in a single gesture. A payment flow with biometric confirmation is both PSD2-compliant and lower friction than a password + OTP flow. Design authentication to be secure by default and frictionless when the risk level permits it.

  Axiom:

• The core banking integration is the hardest part

  Core banking systems (Temenos T24, Infosys Finacle, Oracle FLEXCUBE, Mambu) have their own data models, API conventions and performance characteristics. Building a digital channel that directly depends on core banking API calls for every screen will expose core system latency to users. The correct architecture is an API layer that aggregates and caches core data, handles the impedance mismatch between the core's data model and the digital channel's requirements, and provides a consistent interface regardless of which core system sits behind it.

  Axiom:

• Spending insights drive engagement

  Account balance and transaction history are table stakes. Categorised spending, merchant enrichment (showing "Costa Coffee" instead of "CSTCFF HBRDY STREET"), monthly spending trends and proactive insights ("You spent 30% more on dining this month") are the engagement differentiators. These require transaction enrichment infrastructure — merchant name normalisation, category classification, and an analytics layer that processes transactions in near real-time.

  Axiom:

The digital banking platform decisions that matter.

Each choice defines the channel's performance, compliance standing and user experience.

• Web + mobile or mobile-first?

  Impact: Web + mobile for retail banks targeting all demographics. Mobile-first for neobanks targeting digital-native younger users. PWA reduces development cost but limits biometric authentication and push notification capabilities on iOS.

  • Mobile-first only — lower initial cost, limits older demographic segments
  • Web + mobile — maximum reach, highest development cost
  • Progressive web app (PWA) — one codebase for web and mobile, limited native capabilities
  • White-label app + custom portal — faster mobile, custom web

• Build vs buy the mobile app?

  Impact: White-label for incumbents who need speed to market and have the licensing budget. Custom React Native for banks where the mobile experience is a primary competitive differentiator.

  • Custom React Native — full control, 6-12 months to build
  • White-label banking app (Backbase, Temenos Infinity) — faster, licensing cost, limited differentiation
  • API-first + third-party SDK — use banking SDK for transactions, custom UI layer
  • Hybrid (custom shell + embedded web views for complex screens)

• Real-time balance update approach?

  Impact: WebSocket for in-app real-time balance updates while the app is open. Push notifications for background updates when the app is closed. Short polling is not acceptable for a production banking app — 60-second stale balance is visibly wrong after a transaction.

  • WebSocket subscription — real-time, maintains persistent connection, server infrastructure
  • Server-sent events (SSE) — one-way real-time, simpler than WebSocket
  • Short polling — simplest, delay proportional to poll interval, wasteful
  • Push notification only — no in-app real-time, good enough for most use cases

• Core banking integration pattern?

  Impact: API aggregation layer (BFF pattern) is the correct architecture — it isolates the digital channel from core banking system latency, enables caching of frequently-read data, and provides a migration path if the core banking system changes.

  • Direct API calls to core — simple, performance depends entirely on core system
  • API aggregation layer — caches and aggregates core data, buffers core performance
  • Event-driven integration — core publishes events, digital channel subscribes
  • BFF (backend-for-frontend) per channel — channel-specific API optimisation

• Transaction enrichment?

  Impact: Full enrichment via a transaction enrichment API (Plaid, Tink, or Ntropy) is the standard for consumer digital banking. The cost is $0.01-0.05 per enrichment — justified by the engagement improvement from showing clean merchant names and spending categories.

  • Raw transaction data — no enrichment, show exactly what the core sends
  • Merchant name normalisation only — clean up merchant names from card network format
  • Full enrichment (merchant + category + logo) — best UX, requires enrichment API (Plaid, Tink)
  • ML-based categorisation — custom model, highest accuracy for your specific transaction set

• Notification infrastructure?

  Impact: OneSignal or custom notification service (SNS + FCM + APNs) for any bank where notification latency matters. Never rely on the core banking system for real-time transaction notifications — core batch processing introduces unacceptable latency for the sub-5-second standard.

  • Firebase Cloud Messaging (FCM) only — free, Android-focused, iOS support via APNs bridge
  • OneSignal — managed, multi-channel (push + email + SMS), per-notification cost at scale
  • Custom notification service — full control, highest engineering cost
  • Core banking notification — rely on core system for notifications, latency risk

What PROPELOO builds.

• Retail Digital Banking

  Web and mobile banking for retail customers — account overview, transaction history, domestic and international payments, card management and spending insights.

• Business Internet Banking

  Corporate banking portal with multi-user access, payment approval workflows, bulk payment upload, real-time account balance, SWIFT initiation and bank statement download.

• Open Banking Platform

  PSD2/Open Banking API platform — AISP and PISP APIs for third-party providers, OAuth 2.0 consent management, SCA, developer portal and API monitoring.

• Digital Banking Modernisation

  Replace legacy internet banking with modern React/React Native platform — same core integration, new digital experience, mobile app and real-time notification infrastructure.

• Banking Super-app

  Banking plus marketplace — embedded insurance, investments, buy now pay later within the banking app. Third-party product integration via Open Banking APIs.

• API Banking Platform

  Developer API platform for business customers — account balance and transaction retrieval, payment initiation, webhook subscriptions and API key management portal.

The digital banking stack.

Channel engineering, core integration and real-time infrastructure each require specific tooling.

• Web Frontend

  Stack: React, Next.js, TypeScript, TanStack Query, WebSocket client, Tailwind CSS

• Mobile

  Stack: React Native, Expo, React Native Biometrics, Notifee (push), react-native-keychain

• Backend / BFF

  Stack: Node.js (TypeScript), FastAPI, PostgreSQL, Redis (session/cache), WebSocket (Socket.io)

• Core Integration

  Stack: Temenos API, Mambu API, Finacle Webservices, Custom adapter pattern, Apache Kafka

• Notifications

  Stack: Firebase FCM, Apple APNs, OneSignal, AWS SNS, Custom notification service

• Security & Compliance

  Stack: OAuth 2.0 / OIDC, FIDO2 / WebAuthn, Hardware Security Module, Fraud detection ML, PSD2 SCA library

Digital banking security must balance protection with friction.

High security with low friction is achievable through risk-based authentication.

• Strong Customer Authentication

  PSD2 requires SCA for most payment operations — two factors from: something you know (PIN/password), something you have (device), something you are (biometric). Biometric + device binding satisfies SCA in a single gesture. Step-up authentication (require SCA again) for high-value transactions above configurable thresholds.

• Device Binding & Trust

  Device binding associates a specific device with an account — a new device login triggers step-up authentication and notification to other registered devices. Device fingerprinting detects account access from unrecognised devices even if credentials are correct.

• Session Management

  Banking sessions must expire after inactivity (typically 5-10 minutes), require re-authentication for high-risk operations, invalidate on logout from all devices and detect concurrent sessions from different locations.

• Payment Fraud

  Confirmation of Payee (CoP) for new beneficiaries, real-time transaction risk scoring, 24-hour delay on first payment to new payees above a threshold, and out-of-band confirmation (SMS/push) for transactions above configurable limits.

• API Security

  Open Banking APIs require mTLS between TPP and bank, OAuth 2.0 consent with explicit customer authorisation, access token expiry and refresh, rate limiting per TPP and comprehensive API access logging for regulatory audit.

• Data Protection

  Account numbers, sort codes and balances are PII under GDPR. Field-level encryption for sensitive data, data minimisation in API responses, right of erasure workflow and data retention automation.

From core banking to digital channel.

1. 01. Core Banking Audit

   Assess existing core banking APIs, data model, performance characteristics and integration approach.

2. 02. Channel Architecture

   BFF design, real-time infrastructure, notification architecture, authentication model and Open Banking API scope.

3. 03. BFF & Core Integration

   API aggregation layer development, core banking adapter, caching strategy and data model mapping.

4. 04. Web Banking Portal

   React/Next.js web banking development — account overview, payments, transaction history, statements.

5. 05. Mobile Banking App

   React Native mobile app — biometric auth, real-time feed, payment initiation, card management, push notifications.

6. 06. Open Banking APIs

   PSD2/Open Banking API development, OAuth consent management, developer portal and SCA implementation.

7. 07. Launch & Monitoring

   Phased rollout, real-time monitoring, notification delivery tracking and performance optimisation.

Digital Banking Platform Engagements

Production-grade retail and commercial digital banking systems built for scale, resilience and compliance.

• Next-Gen Mobile Banking Platform with Multi-Currency Accounts

  Challenge: Neobank needed complete digital banking mobile application with real-time balance updates, instant P2P transfers, and multi-currency IBANs.

  Architecture: Microservices architecture with Kafka event bus for real-time transaction streaming, Redis caching for instant balance queries, Plaid integration for bank linking, and ISO 20022 compliance data layer.

  Outcome: Supported 350,000 active accounts in year one. 99.99% system uptime during peak payroll processing days. Average transaction processing latency under 120ms.

• Core Banking Integration & Real-Time Card Issuing System

  Challenge: FinTech needed to issue physical and virtual debit cards with real-time spend authorization and dynamic fraud filtering.

  Architecture: Sub-50ms card authorization webhook engine connecting Marqeta to internal ledger, automated balance reservation, and integration with Mambu core banking platform for overnight reconciliation.

  Outcome: Processed $65M in monthly card transactions with 99.995% webhook uptime. Zero ledger discrepancies in automated daily settlement runs.

• Automated KYC/AML & Onboarding Workflow Engine

  Challenge: High customer drop-off (42%) during legacy manual identity verification and account approval.

  Architecture: Biometric identity verification with liveness detection, automated sanctions and PEP screening, dynamic risk scoring rules engine, and instant account provisioning for low-risk applicants.

  Outcome: Onboarding completion rate increased from 58% to 91%. Verification time reduced from 24 hours to 90 seconds for 85% of users.

Frequently Asked Questions