Fintech Software Development: How Smart Maple Builds Compliant Financial Products [2026]

Fintech software development fails in predictable ways. The team builds the feature set correctly, launches on time, and then discovers that their payment gateway integration does not handle idempotency, their KYC flow is missing liveness detection, their ledger drifts by fractions of a cent at scale, or their fraud system generates false positives at a rate that is alienating legitimate customers.

These failures are not engineering incompetence. They are the result of building fintech with a general-purpose software development mindset, without the specific domain knowledge that financial systems require. A checkout flow that crashes loses a sale. A ledger that loses track of customer funds is a regulatory incident.

Smart Maple builds fintech software systems — payment platforms, open banking integrations, digital wallet applications, and RegTech compliance platforms. This page describes how we approach each major fintech product category, what the engineering work actually involves, and what outcome teams should expect.

Fintech Software Development: What Makes It Different

The core difference between fintech engineering and standard web application development is consequence asymmetry. A bug in your e-commerce recommendation engine costs you conversion rate points. A bug in your payment processing logic costs you regulatory standing and customer trust.

This asymmetry drives three engineering principles we apply to every fintech project:

Correctness over velocity: in fintech, shipping a slightly wrong solution is worse than shipping a slightly late correct one. We design test suites to cover financial edge cases — concurrent debit from a shared account, failed payment during partial settlement, duplicate webhook delivery — before we write production code.

Compliance as architecture: regulatory requirements are not a checklist applied before launch. They are constraints that shape the data model, the API design, the deployment architecture, and the operational procedures. We integrate PCI DSS requirements into our database schema decisions, AML/KYC flows into our onboarding architecture, and audit logging into our observability stack.

Defense in depth for financial data: payment card numbers, bank account details, and customer identity documents require layered protection. Tokenization at the point of capture, encryption at rest, access controls at the application layer, and network segmentation at the infrastructure layer — each layer independently sufficient to prevent exposure if another layer fails.

Payment Platform Development

We build payment processing platforms across three segments:

Payment Gateway Integration

Integrating with payment gateways (Stripe, Adyen, Braintree, iyzico) is straightforward in sandbox; robust in production requires specific engineering:

Idempotency: every payment API call gets a unique idempotency key. If the request times out, we retry with the same key — the gateway processes it once, regardless of how many times we submit it. Without idempotency, network failures produce double charges.

Webhook reliability: payment state changes arrive via webhook. We design webhook consumers to acknowledge immediately (return 200 before processing), process asynchronously via a job queue, and handle at-least-once delivery (gateway retries until acknowledgment). We store and deduplicate webhook event IDs to prevent processing the same state change twice.

3D Secure 2.0: risk-based authentication reduces friction for low-risk transactions while maintaining security for high-risk ones. We implement 3DS2 with fallback to 3DS1 for cards that don't support the newer protocol. Challenge rate targets: < 15% of transactions (higher than this suggests your transaction risk scoring is too conservative).

Reconciliation: daily reconciliation comparing internal transaction records against gateway settlement reports catches discrepancies before they become accounting problems. We build this into the platform from the first production transaction.

Digital Wallet and E-Money Platforms

Digital wallet development requires the compliance architecture to be in place before any customer transaction:

• Ledger engine using double-entry accounting with PostgreSQL transactions and optimistic locking for concurrent balance updates
• Card tokenization via Visa Token Service (VTS) or Mastercard MDES for NFC payments; processor vault tokenization for card-not-present
• Host Card Emulation (HCE) implementation for Android NFC tap-to-pay
• KYC/AML integration with third-party identity verification (Jumio, Onfido) and transaction screening (Dow Jones Watchlist, OFAC) from onboarding day one

In digital wallet projects at Smart Maple, we implement the ledger and KYC services in the first two weeks of development — before any payment flow exists. This means every feature built afterward is built on a foundation that already handles fund tracking correctly.

Payment Infrastructure (PSP Orchestration)

Larger fintech platforms need to route payments across multiple processors based on cost, success rate, and geographic coverage. We build PSP orchestration layers that:

• Route transactions to the lowest-cost processor with acceptable authorization rates for the BIN/country combination
• Failover to a secondary processor within 200ms when the primary returns an error
• Track authorization rates per BIN/processor pair and rebalance routing rules automatically
• Provide a unified settlement view across all downstream processors

Open Banking API Development

We build financial data aggregation platforms and payment initiation services compliant with PSD2/PSD3 (Europe), UK Open Banking, and equivalent frameworks.

FAPI security implementation: Financial-grade API profiles require mutual TLS, JWS request object signing, and PKCE. We implement these as a shared client library used across all bank integrations — not reinvented per-bank.

Consent management: every account data access requires a valid customer consent grant. We build consent as a first-class domain entity with a full state machine (awaiting authorisation → authorised → revoked/expired) and middleware that validates consent scope before every API call.

Multi-bank normalization: bank API responses diverge in field names, account type codes, and transaction categorizations even within "standard" specifications. Our integration architecture normalizes all bank responses to a canonical domain model before they reach business logic — bank-specific quirks are isolated to thin adapter layers.

Payment initiation: PISP implementation requires per-payment consent, SCA redirect handling, and robust payment status tracking. We implement idempotency keys and persistent payment state machines so that network failures between submission and bank processing are recoverable.

RegTech and Compliance Platform Development

Compliance is automatable. The platforms we build handle:

Automated KYC: document capture → OCR extraction → identity verification API → liveness check → sanctions screening → risk scoring. Target: verified customer in under 3 minutes for standard profiles; enhanced due diligence flagged for human review.

AML transaction monitoring: rule-based screening (velocity limits, sanctions list hits, unusual geography) plus ML anomaly detection for patterns not covered by rules. STR (Suspicious Transaction Report) generation and regulatory filing automation.

Regulatory reporting automation: PSD2 reporting, e-money institution safeguarding reports, AML periodic reports. Built as scheduled jobs that pull from the operational database, apply reporting period logic, and generate regulator-format outputs.

Audit trails: immutable, append-only event logs for every financial transaction and compliance-relevant action. Queryable for regulator audits. Stored separately from the operational database to prevent accidental or malicious modification.

Technology Stack

Our standard fintech engineering stack:

Backend: Node.js (TypeScript) with NestJS for structured service architecture. Python for ML-based fraud detection models and data pipeline components. PostgreSQL for all financial data (ACID compliance, strong consistency). Redis for session management, rate limiting, and short-lived caches.

Mobile: React Native for cross-platform wallet and payment apps, with native modules for platform-specific features (NFC, Secure Enclave/Keystore, biometrics).

Infrastructure: AWS with VPC segmentation (application layer, data layer, admin layer in separate subnets). Application Load Balancer terminating all internet traffic. No database ports exposed externally. AWS Secrets Manager for all credentials. CloudWatch for monitoring; PagerDuty for incident alerting.

Security: TLS 1.3 on all connections, AES-256 encryption at rest for financial data, column-level encryption for PAN/IBAN/identity document fields, HashiCorp Vault for secrets management in multi-environment deployments.

Project Structures

MVP engagement (8-12 weeks): Core fintech product — payment gateway integration, basic ledger, KYC onboarding, fraud rule engine. Scope-limited to prove market fit with a compliant foundation. Typical cost: $35,000–$55,000.

Full-platform engagement (16-24 weeks): Production-grade platform with full compliance stack, multi-bank open banking integration, ML fraud detection, regulatory reporting. Typical cost: $90,000–$150,000.

Technical partnership: Ongoing engineering capacity embedded in your team for product iteration, compliance updates as regulations evolve, and performance optimization at scale.

Fraud Detection and Risk Scoring

Fraud detection is a continuous engineering investment, not a one-time implementation. The threat landscape evolves as fraudsters discover and exploit new patterns — your detection system must evolve with it.

For fintech applications we build, fraud detection operates in three layers:

Transaction-time rules (synchronous, < 100ms): high-confidence fraud signals that can block a transaction immediately. Examples: transaction amount 10x above customer's historical maximum, device fingerprint mismatch with registered devices, impossible geographic velocity (two transactions 2,000 km apart within 10 minutes). These rules run inline in the payment processing path.

Near-real-time ML scoring (asynchronous, < 5 seconds): a risk score is computed for every transaction against an ML model trained on historical labeled fraud data. Score thresholds trigger actions — approve, approve with step-up authentication, or hold for review. The ML model is retrained monthly on new data and A/B tested against the production model before full deployment.

Behavioral analytics (batch, daily): pattern analysis across session behavior, device history, and transaction sequences that are invisible at the individual transaction level. Money mule networks, coordinated account takeover campaigns, and card testing attacks appear clearly in behavioral analysis even when individual transactions pass real-time checks.

The fraud detection pipeline architecture: all transactions flow through a Kafka event stream. The synchronous rule engine consumes from the stream and writes a risk decision back within 100ms. The ML scoring service consumes in parallel and updates the transaction risk record. The behavioral analytics job runs nightly against a BigQuery or Redshift data warehouse.

Security Architecture for Financial Data

Financial data has specific security requirements beyond standard web application security. The most important:

Column-level encryption for PII and financial data: full-disk encryption is insufficient for databases holding payment card data, bank account numbers, or identity document information. These fields must be encrypted at the column level with keys managed separately from the database — typically via AWS KMS or HashiCorp Vault. This means a database dump without the encryption keys is unusable.

PCI DSS scoping and reduction: any system that touches payment card data is in PCI DSS scope. The fastest way to reduce scope is to never let card data enter your systems — using payment processor hosted fields (Stripe Elements, Adyen Web Drop-in) means card numbers are transmitted directly from the browser to the processor; your servers never see them. If you need to store card data for recurring payments, use processor tokenization and store only the token.

Secrets management: API keys, database passwords, JWT signing keys, and service-to-service authentication credentials must never appear in code, configuration files, or environment variables on developer machines. We use HashiCorp Vault for dynamic secrets (credentials that expire and rotate automatically) and AWS Secrets Manager for static credentials. Key rotation schedules: API keys rotated every 90 days, JWT signing keys rotated every 30 days.

Network segmentation: the payment processing service, the KYC/AML service, and the compliance reporting service each run in separate VPC subnets with explicit allow-only security group rules. The payment processing subnet has no direct internet access — all outbound traffic goes through a NAT gateway. This limits blast radius if one service is compromised.

Deployment and Observability

Fintech platforms require higher operational standards than standard web applications:

SLA targets: 99.9% availability (8.7 hours maximum downtime/year) for standard fintech platforms; 99.95% (4.4 hours/year) for payment processing infrastructure.

Zero-downtime deployments: database migrations must be backward-compatible with the running application version during the deployment window. We use a multi-phase migration pattern: add new column (safe), deploy application that reads from both old and new, backfill new column, deploy application that reads from new only, drop old column.

Distributed tracing: every financial transaction generates a trace ID that follows it through payment processing, fraud scoring, ledger recording, and notification. When a transaction fails or produces an unexpected outcome, the trace gives a complete picture of every service interaction in under 30 seconds. We use OpenTelemetry for instrumentation and Jaeger or AWS X-Ray for trace storage and visualization.

Financial metrics dashboards: beyond standard infrastructure metrics, fintech operations require real-time visibility into authorization rates per payment method, fraud rates, KYC pass/fail rates, and AML alert volumes. Prometheus with Grafana dashboards, or Datadog's APM for larger deployments.

Incident response playbooks: for a payment outage, a KYC service failure, or a data breach, you need a documented response procedure with clear ownership at every step. We help build these playbooks as part of every fintech engagement — the 3 AM page is the wrong time to decide who is responsible for notifying the regulator.

What to Expect

We start every fintech engagement with a compliance architecture review: identifying the regulatory obligations that apply to your product, mapping those to specific technical requirements, and confirming those requirements are addressed in the initial design. This review happens before any code is written.

The result is a platform that works correctly at launch — correct ledger entries from the first transaction, KYC-verified customers from the first onboarding, fraud detection active from the first payment — and continues to work correctly as transaction volumes grow and regulatory requirements evolve.

For fintech software development projects, visit smart-maple.com.