Tutorial: Learn Fintech from Scratch (2026)
Fintech is the intersection of finance and technology — building systems that move, manage, and secure money. After building payment processing pipelines for a fintech startup that grew to process $500M annually, I have learned that fintech development is 20% feature code and 80% compliance, reliability, and reconciliation. Getting a transaction wrong once costs more than shipping late.
This tutorial covers payment processing, banking APIs (Open Banking), regulatory compliance (PCI DSS, KYC, AML), digital wallets, and the architectural patterns that make fintech systems auditable, idempotent, and highly available.
Payment Processing Pipeline
A payment pipeline moves money from payer to payee through a series of steps: authorization (is the card valid?), capture (reserve funds), settlement (transfer funds), and reconciliation (match records). Each step must be idempotent — retrying a step must produce the same result as the first attempt. Use idempotency keys: a unique identifier per request that the server deduplicates.
Stripe, Adyen, and Braintree provide APIs that abstract most of this complexity. The key integration pattern: create a payment intent, confirm with the payment method, and listen for webhooks (payment_intent.succeeded, payment_intent.payment_failed) to update your order state.
import stripe
stripe.api_key = os.environ['STRIPE_SECRET_KEY']
# Idempotent payment creation
def create_payment(amount, currency, idempotency_key):
try:
payment = stripe.PaymentIntent.create(
amount=amount,
currency=currency,
idempotency_key=idempotency_key
)
return payment
except stripe.error.IdempotencyError:
return get_existing_payment(idempotency_key)
# Webhook handler
@app.post('/webhooks/stripe')
async def stripe_webhook(payload: Request):
event = stripe.Webhook.construct_event(
await payload.body(),
payload.headers.get('stripe-signature'),
webhook_secret
)
if event.type == 'payment_intent.succeeded':
await update_order_status(event.data.object)
return {'status': 'ok'}Open Banking and Banking APIs
Open Banking (PSD2 in Europe, Consumer Data Right in Australia) requires banks to expose customer data and payment initiation through standardized APIs. The UK's Open Banking standard uses OAuth 2.0 with FAPI (Financial-grade API) profiles: PAR (Pushed Authorization Requests), JWT-secured authorization requests, and certificate-bound access tokens.
Third-party providers (TPPs) register with regulatory bodies, obtain certificates, and use them to authenticate with banks. The flow: redirect user to their bank's authorization page, get a token, call the AISP (Account Information Service Provider) API for balances and transactions or the PISP (Payment Initiation Service Provider) API to make payments.
// Open Banking token request with MTLS
const fs = require('fs');
const tokenResponse = await fetch('https://bank.example.com/token', {
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded',
'Authorization': `Basic ${base64(clientId + ':' + clientSecret)}`
},
body: new URLSearchParams({
grant_type: 'client_credentials',
scope: 'openid accounts payments',
client_assertion_type: 'urn:ietf:params:oauth:client-assertion-type:jwt-bearer',
client_assertion: signedJwt
}),
clientCert: fs.readFileSync('transport.pem'),
clientKey: fs.readFileSync('transport-key.pem')
});
const token = await tokenResponse.json();
const accounts = await fetch('https://bank.example.com/open-banking/v3.1/aisp/accounts', {
headers: { 'Authorization': `Bearer ${token.access_token}` }
});PCI DSS Compliance
Any system that stores, processes, or transmits cardholder data must comply with PCI DSS. The easiest path: never touch raw card numbers. Use a payment gateway's hosted fields or Elements (Stripe, Braintree) that tokenize the card data before it reaches your server. The token is useless to an attacker — it can only be used with the gateway.
If you must handle raw PAN (Primary Account Numbers), you are in PCI Scope 1: encryption at rest (AES-256), encryption in transit (TLS 1.3), access controls, audit logging, and quarterly scans by an Approved Scanning Vendor (ASV). Most fintech startups avoid this entirely by using a payment facilitator.
# PCI-compliant card tokenization (Stripe Elements)
# Stripe.js creates a token on the client, never touching your server
// Frontend
const stripe = Stripe('pk_test_...');
const elements = stripe.elements();
const cardElement = elements.create('card');
cardElement.mount('#card-element');
const { token, error } = await stripe.createToken(cardElement);
if (token) {
fetch('/charge', { method: 'POST', body: JSON.stringify({ token: token.id }) });
}
# Backend - only receives token, no card data
@app.post('/charge')
def charge(request):
token = request.json['token']
stripe.Charge.create(amount=2000, currency='usd', source=token)KYC and AML Verification
Know Your Customer (KYC) and Anti-Money Laundering (AML) are regulatory requirements for any financial service. KYC verifies user identity through document verification (passport, driver's license), biometric matching, and database checks (watchlists, PEPs). AML monitors transactions for suspicious patterns: structuring (multiple transactions just below reporting thresholds), rapid movement through accounts, and high-risk jurisdictions.
Third-party verification services (Onfido, Jumio, Persona, Veriff) handle document verification via SDKs. They return structured data: verified name, date of birth, document validity, and liveness check result. AML screening (ComplyAdvantage, Chainalysis for crypto) checks against sanctions lists and adverse media.
const { Onfido } = require('@onfido/api');
const onfido = new Onfido({ apiToken: process.env.ONFIDO_API_TOKEN });
async function verifyUser(userId, documentFront, documentBack, livePhoto) {
const applicant = await onfido.applicant.create({
firstName: 'John',
lastName: 'Doe',
email: 'john@example.com'
});
const check = await onfido.check.create({
applicantId: applicant.id,
reportNames: ['document', 'facial_similarity_photo', 'identity_enhanced']
});
const result = await onfido.check.retrieve(check.id);
return result.result === 'clear'; // clear, consider, or unverified
}Digital Wallets and Ledgers
A digital wallet manages user balances, tracks transactions, and enforces business rules. The ledger is a double-entry accounting system: every financial event is a debit from one account and a credit to another. The sum of all debits must equal the sum of all credits — this invariant is your most important constraint. Use decimal types (not floats) for monetary values.
For high-throughput ledgers, use a dedicated ledger service (Moov, Modern Treasury, or a custom PostgreSQL-based system with SERIALIZABLE isolation). Each transaction consists of entries, each with a unique ID, account, amount, currency, and metadata. Reconcile daily with bank statements.
BEGIN;
-- Double-entry wallet transfer
-- Deduct from sender
INSERT INTO ledger (account_id, amount, currency, direction, reference)
VALUES ($sender_id, $amount, 'USD', 'DEBIT', $tx_ref);
UPDATE wallets SET balance = balance - $amount
WHERE account_id = $sender_id AND balance >= $amount;
-- Credit to recipient
INSERT INTO ledger (account_id, amount, currency, direction, reference)
VALUES ($recipient_id, $amount, 'USD', 'CREDIT', $tx_ref);
UPDATE wallets SET balance = balance + $amount
WHERE account_id = $recipient_id;
COMMIT;Fraud Detection Systems
Real-time fraud detection evaluates each transaction against dozens of signals before authorization. Rules-based detection catches known patterns: velocity checks (more than 3 transactions in 5 minutes), amount thresholds, and geo-anomalies. Machine learning models capture unknown patterns: isolation forests for anomaly detection, gradient boosting for fraud probability scoring.
Feature engineering is the critical step: aggregate features (user's average transaction amount, number of declined cards), behavioral features (time between login and payment), and network features (IP reputation, device fingerprint). Model inference must complete in under 100ms to not degrade payment UX.
import pandas as pd
from xgboost import XGBClassifier
features = [
'txn_amount', 'user_avg_amount', 'user_txn_count_1h',
'device_new', 'ip_risk_score', 'geo_distance_km',
'card_declines_24h', 'hour_of_day', 'is_international'
]
def score_transaction(txn, user, device, ip):
x = pd.DataFrame([{
'txn_amount': txn.amount,
'user_avg_amount': user.avg_txn_amount,
'user_txn_count_1h': user.txn_count_last_hour,
'device_new': device.is_new,
'ip_risk_score': ip.risk_score,
'geo_distance_km': haversine(user.last_location, txn.location),
'card_declines_24h': user.card_declines_24h,
'hour_of_day': txn.created_at.hour,
'is_international': user.country != txn.country
}])
fraud_prob = model.predict_proba(x)[0, 1]
if fraud_prob > 0.8:
return 'DECLINE'
elif fraud_prob > 0.5:
return 'REVIEW'
return 'APPROVE'Frequently Asked Questions
What regulatory requirements do I need to know?
At minimum: PCI DSS (card payments), KYC/AML (identity verification), GDPR (data privacy), and PSD2/Open Banking (if operating in Europe). Consult a compliance lawyer before processing live transactions.
How do I handle chargebacks?
Build a dispute management system: when a chargeback is filed, collect evidence (IP logs, delivery confirmation, communication records) and submit via the card network's portal. Maintain a chargeback ratio below 0.5% to avoid network fines.
Should I build or buy payment infrastructure?
Start with Stripe/Adyen for payments. Build your own wallet/ledger system. Buy KYC/AML verification services. Build fraud detection on top of open-source models. Only build core infrastructure when off-the-shelf solutions cannot meet your requirements.
How do I ensure 99.99% uptime for payments?
Multi-region deployment, database replication with automatic failover, idempotent retry logic, circuit breakers for downstream dependencies, and chaos engineering. The payment pipeline must handle partial failures gracefully — a transaction can succeed at Stripe but fail to reach your database.
Originally published on Ayodhyyya. Last updated June 1, 2026.