Financial App Development

Companies building financial software today operate in a more technically demanding regulatory environment than any previous wave of FinTech. PSD2 mandates open banking API access to account data and payment initiation across EEA banks. FedNow and Faster Payments push real-time settlement expectations into every consumer-facing product. The Consumer Duty (UK) and MiFID II impose outcome-based obligations on firms distributing financial products. And the embedded finance wave has every vertical SaaS product (from logistics to healthcare to HR) exploring financial product distribution via Banking-as-a-Service (BaaS) partnerships. Scrums.com builds the engineering infrastructure behind financial platforms: open banking integrations, payment orchestration layers, digital lending origination, wealth management platforms, and embedded finance modules, with the compliance architecture and security controls that regulated financial products require from day one.

Our dedicated engineering teams have built financial platform infrastructure for neobanks and e-money licence holders, FinTech startups building lending and payment products, wealth management platforms, and enterprise software vendors embedding financial features. We deliver dedicated squads (senior engineers, tech leads, QA) integrated into your sprint cycle, typically deploying first production infrastructure within 21 days of kickoff.

Core Architecture of a Financial Platform

Four platform patterns dominate B2B financial app engineering, each with distinct architecture requirements.

Open Banking and Account Data Aggregation

Bank connectivity via PSD2/Open Banking APIs (UK Open Banking, Berlin Group NextGenPSD2) or aggregation platforms (TrueLayer, Plaid, Tink, Yapily) requires consent management at the account level, token lifecycle management (access and refresh tokens per ASPSP), periodic re-authentication enforcement, and consent withdrawal cascades. Aggregated transaction data normalisation (categorisation, merchant normalisation, currency conversion) feeds downstream affordability assessments, financial health scoring, and cashflow analytics. Webhook infrastructure propagates balance and transaction updates to downstream consumers within seconds of bank notification.

Payment Orchestration and Processing

A payment orchestration layer selects the optimal payment rail for each request based on cost, speed, currency, and counterparty capabilities, choosing between card (Stripe, Adyen, Checkout.com), bank transfer (Bacs, SEPA, FedNow, SWIFT), or instant payment (Faster Payments, SEPA Instant). Intelligent retry logic applies per-failure-reason strategies: network timeouts retry immediately, insufficient funds retry after statement date, fraud blocks route to alternative method. Idempotency keys at the API layer prevent duplicate charges on network failures. Payment status state machines (Pending, Authorised, Captured, Settled, Refunded, Disputed) drive downstream reconciliation and ledger posting.

Digital Lending and Credit Origination

Loan origination systems manage the full application lifecycle: identity verification (KYC), affordability assessment (open banking transaction analysis, credit bureau integration via Experian, Equifax, and TransUnion), underwriting rule engine (scorecard-based or ML model inference), offer generation with APR/APRC calculation compliant with TILA/Regulation Z and the UK Consumer Credit Act, e-signature workflow, and drawdown initiation. The credit decisioning engine separates model inference from business rules: a model score feeds into a configurable rules engine that applies product-specific cutoffs, regulatory caps, and manual review routing. Every decision stores the input features and output for adverse action notice generation.

Wealth Management and Portfolio Infrastructure

Wealth platforms require: account aggregation across custodians (via FIX or proprietary APIs), order management system (OMS) with pre-trade compliance checks (investment policy statement validation, concentration limits, regulatory suitability scoring under MiFID II), portfolio rebalancing engine (drift-based or calendar-based with tax-lot optimisation), performance attribution (time-weighted and money-weighted returns per GIPS standards), and client reporting (PDF factsheets, PRIIP KIDs for packaged retail investment products). Robo-advisor variants add risk profiling questionnaire, model portfolio mapping, and automated rebalancing triggers.

Compliance Architecture: PSD2, AML/KYC, Consumer Duty, and MiFID II

Financial software operates under overlapping regulatory obligations that affect data model and API design before the first transaction is processed. The four frameworks below cover the majority of B2B financial platform engineering requirements.

PSD2, Open Banking, and Payment Services Regulation

PSD2 Strong Customer Authentication (SCA) requirements apply to payment initiation: 3DS2 for card payments, PISP-initiated payments require SCA at the ASPSP. Merchant-initiated transactions (MITs), recurring payments established under SCA, and transaction risk analysis (TRA) exemptions (sub-30 EUR/GBP, low-fraud-rate merchant, trusted payee) must be implemented correctly to avoid authorisation failures at scale. The incoming UK PSR (Payment Services Regulation) tightens liability rules for APP fraud, requiring real-time payee confirmation (Confirmation of Payee) and fraud reimbursement obligations that affect product design decisions from the outset.

AML/KYC and Financial Crime Prevention

Anti-money laundering compliance requires: customer due diligence (CDD) at onboarding (identity document verification, liveness check, sanctions and PEP screening via Refinitiv, Dow Jones, or ComplyAdvantage), enhanced due diligence (EDD) for high-risk customers, ongoing transaction monitoring with configurable rule-based and ML anomaly detection, and suspicious activity report (SAR) filing workflow with regulator portal integration. The risk scoring model must be documented and explainable: a black-box ML model that produces SAR-triggering alerts without an audit trail is not compliant with FCA/FinCEN expectations.

FCA Consumer Duty and Treating Customers Fairly

Consumer Duty (effective July 2023) requires financial product firms to demonstrate good consumer outcomes across four areas: products and services, price and value, consumer understanding, and consumer support. From an engineering perspective this requires: outcome monitoring dashboards fed by product analytics, fair value assessment tooling that compares pricing against consumer benefit realised, consumer understanding testing workflows, and complaint root cause analysis pipelines. These are not aspirational metrics: the FCA expects firms to have systematic monitoring evidence at supervisory review.

MiFID II and Investment Product Distribution

MiFID II product governance requires manufacturers to define a target market for each investment product and distributors to confirm their clients fall within that target market. The target market check must run at point of sale and be logged. Ex-ante cost disclosure (PRIIP KID for retail, MiFID II cost and charges illustration for professional) must be presented before order execution. Transaction reporting to regulators (ESMA, FCA) via ARM (Approved Reporting Mechanism) must occur within T+1 for in-scope instruments, with LEI validation and instrument reference data lookup against FIRDS.

Scrums.com's mobile app development teams build financial platform infrastructure covering open banking, payment orchestration, digital lending, and wealth management across PSD2, AML/KYC, Consumer Duty, and MiFID II compliance frameworks.

Technology Stack for Financial Platforms

Financial platform technology choices must balance correctness (immutable transaction records, decimal arithmetic), regulatory compliance (audit trails, SCA flows), and throughput (payment processing at scale). No single stack fits every financial product; choices depend on the platform type and regulatory surface area.

Core Backend Services

Java Spring Boot or Kotlin for payment processing and transaction services: strong typing, mature BigDecimal handling, and JVM reliability under continuous transaction load. Python for ML-based credit scoring, fraud detection, and affordability assessment models (scikit-learn, XGBoost, LightGBM). Node.js/TypeScript for API gateway, webhook delivery, and event-driven notification services. Go for high-throughput payment processing components where single-digit millisecond latency is required.

Database and Event Infrastructure

PostgreSQL with append-only partitioned tables for financial transaction records and immutable audit logs. Redis for real-time FX rate caching, session state, and idempotency key storage. Apache Kafka for event-driven payment lifecycle propagation, audit event streaming, and AML transaction monitoring feeds. Elasticsearch for transaction search, AML alert analytics, and MiFID II reporting queries.

Payment and Banking Connectivity

Stripe (Connect for marketplace, Elements for UI, Radar for ML fraud scoring), Adyen (Terminal API for in-person, Checkout API for online), or Checkout.com for card processing. GoCardless for BACS/SEPA Direct Debit mandates and instant bank pay. Modulr, Banking Circle, or Currencycloud for account issuance, FX conversion, and multi-currency payment rails. SWIFT gpi Tracker for cross-border payment status. TrueLayer, Plaid, Tink, or Yapily for open banking aggregation.

Compliance and Identity Infrastructure

Onfido, Jumio, or Veriff for KYC document verification and liveness checks. ComplyAdvantage, Refinitiv World-Check, or Dow Jones Risk and Compliance for AML/PEP/sanctions screening. Featurespace ARIC or in-house ML inference for real-time transaction monitoring. DocuSign or YouSign for e-signature on loan agreements and account terms. Sardine, Kount, or in-house models for device fingerprinting and fraud intelligence.

Why Engineering Teams Choose Scrums.com for Financial Platform Development

Across our client engagements building FinTech infrastructure, the most common engineering failure mode is treating financial products as standard CRUD applications: using mutable records for transactions, floating-point arithmetic for monetary values, and building compliance controls as add-ons after the core product is live. Retrofitting an immutable audit trail, SCA compliance, or AML monitoring into a live payment system is significantly more expensive than building it in from the start.

Financial Regulatory Depth

Our engineers have built PSD2-compliant open banking integrations, SCA-exempt recurring payment flows, AML transaction monitoring pipelines, and MiFID II-compliant order management systems. We understand the engineering implications of regulatory requirements before the first line of code is written, which means fewer compliance-driven rewrites late in the build cycle.

Dedicated Squads, Not Rotating Contractors

Each engagement is staffed with a fixed squad (senior engineer, mid-level engineer, tech lead, and QA) who stay with your project for its duration. Financial platforms accumulate context that cannot be transferred via documentation: payment rail quirks, AML rule calibration, and open banking API edge cases per ASPSP. Rotating contractors lose that context; our squads retain it. Typical first production deployment is within 21 days of kickoff.

Built for Regulated Environments

We build financial platforms that produce regulator-ready evidence by default: immutable transaction logs, consent audit trails, AML decision records with input features stored alongside outcomes, and API access logs meeting FCA record-keeping requirements. FCA supervisory visits, PCI DSS QSA assessments, and PSD2 SCA audits all require this evidence: we design for it from day one rather than generating it retrospectively.

Discuss your financial platform requirements at Scrums.com/start-a-project, or explore our FinTech software engineering practice for sector-specific capabilities.

Frequently Asked Questions

How long does it take to build a PSD2-compliant open banking integration?

A production open banking integration via an aggregation platform (TrueLayer, Plaid, Yapily) typically reaches production in 4 to 6 weeks with a dedicated squad, covering consent flows, token lifecycle management, transaction normalisation, and webhook infrastructure. Direct ASPSP integration without an aggregation layer is significantly more complex (each bank has implementation quirks despite the standard) and typically requires 3 to 6 months to achieve reliable coverage across 10+ banks.

What is the engineering difference between a payment gateway integration and a payment orchestration layer?

A payment gateway integration connects your product to a single payment processor. A payment orchestration layer sits above multiple processors and routes each transaction to the optimal rail based on cost, success rate, currency, and geography. Orchestration requires: a normalised payment API that abstracts processor-specific APIs, a routing rules engine configurable without code deployment, idempotency and retry logic per failure type, and a reconciliation layer that maps processor-specific transaction states to your internal state machine. Most scaling FinTech products outgrow single-processor integrations and need orchestration within 12 to 18 months of launch.

How does SCA exemption logic work in a payment processing system?

PSD2 SCA exemptions allow frictionless authorisation for transactions that meet specific criteria: low-value (below 30 EUR/GBP cumulative), trusted payee (pre-authorised by the payer's bank), corporate card transactions, low-risk based on the acquirer's transaction risk analysis (TRA) algorithm. Exemption requests are submitted as flags in the payment initiation API call: the issuing bank decides whether to honour the exemption or step up to 3DS2. Engineering the logic requires: tracking cumulative spend for low-value exemption eligibility, managing trusted payee lists per customer, and monitoring step-up rates per exemption type to recalibrate strategies when an issuer changes behaviour.

How do you handle AML transaction monitoring without generating excessive false positives?

High false positive rates are an operational and regulatory problem: too many alerts overwhelms compliance analysts, while suppressing alerts to manage volume risks missing genuine suspicious activity. The monitoring system should layer rule-based detection (high-velocity transactions, round-number amounts, structuring patterns) with ML-based anomaly scoring calibrated per customer segment. Alert thresholds are tuned using historical SAR conversion rates (the percentage of alerts that result in a filed SAR) with regular recalibration as customer behaviour evolves. Every threshold change must be documented with rationale for regulatory audit purposes.

Can you build a lending origination system that integrates with multiple credit bureaux?

Yes. Credit bureau integrations (Experian, Equifax, TransUnion, Crediva) each have proprietary APIs and data schemas. The origination system abstracts these behind a normalised credit data model (soft search for pre-qualification, hard search for final decisioning) with bureau selection logic configurable per product and jurisdiction. Bureau response caching (typically 30 days for soft searches) reduces cost on high-volume origination funnels. The underwriting rule engine consumes the normalised bureau output alongside open banking affordability data and internal behavioural scores.