FinTechOps

FinTechOps, as this Atlas uses the term, is the operation of money movement inside a financial-technology business. It makes sure each payment is authorised, recorded once in a double-entry ledger, sent over the right payment rail, settled, and reconciled against the records of the processor and the bank, every day, with an owner for every difference.

In one sentence: FinTechOps keeps the promise that money moves exactly once and the books agree with the bank.

It is for payments and backend engineers, payment and finance operations teams, SREs who run payment systems, and founders who must answer to a partner bank or regulator. Sources last verified 2026-10-23.

In searches on 2026-10-23 we found no standard, professional body or certification that defines “FinTechOps”. The string has at least three uses:

1. A company name. FintechOps is a financial-software development firm in Raleigh, North Carolina, which says it helped the forex broker FXCM grow “from a 15-person startup to a publicly-traded company”.^[1][2]
2. “Operations at a fintech”, used loosely for DevOps or IT operations in financial-technology firms.
3. The operations of money movement. Employers staff this work as “Payment Operations”: Wise advertised a team lead for its “Payment Operations Reconciliation team”^[3] and specialists who reconcile bank accounts, payments and transactions and escalate “reconciliation discrepancies in a timely manner”.^[4]

It is also easily confused with FinOps, which the FinOps Foundation defines as “an operational framework and cultural practice which maximizes the business value of technology” through collaboration between engineering, finance and business;^[5] that is cloud and technology spend, taught in FinOps.

• Not financial crime work. Screening, monitoring and suspicious-activity reports belong to FinCrimeOps. The two meet at payment holds and returns.
• Not accounting close. The ledger here is the operational record of customer balances and money in flight. The general ledger and financial statements are finance’s; FinTechOps feeds them reconciled journals.
• Not a start-up niche. Banks, marketplaces and payroll firms run the same practices.

Two documented failures:

1. The ledger and the bank disagree, and nobody can say whose money is where. Synapse ran software between consumer fintech apps and partner banks. The US Consumer Financial Protection Bureau (CFPB) alleged that “as early as September 2023, Synapse’s records did not match the records maintained by that bank”, that funds sat in omnibus accounts held “for the benefit of” consumers, and that consumers could not reach their money “for weeks or months” while banks reconciled. The bankruptcy trustee estimated the shortfall at “between $60 and $90 million”.^[6] A stipulated judgment was entered on 12 September 2025.^[7]
2. A change disrupts banking, including payments, for months. TSB’s April 2018 platform migration disrupted branch, telephone, online and mobile banking until December 2018; UK regulators fined it £48.65m in 2022.^[8] RiskOps covers the programme-risk side.

Smaller failures are daily: a retry charges a customer twice; a short payout goes unnoticed for a month; a card number in a log pulls the platform into PCI DSS scope.

Good looks like: every movement of money has one journal entry, one owner and one reconciled counterpart outside your systems, and every difference has a reason and an age.

Mental model: three answers to “is it paid?”, and two books. Every payment has three answers: the customer view (what the app shows now), the rail view (authorised, cleared, settled, still returnable) and the books view (posted, reconciled, reported). There are always two books: yours (the ledger) and theirs (processor reports, bank statements, scheme files). Most money incidents happen where the answers disagree, for example showing “paid” before settlement, or where your book has no matching line in theirs.

The practices are old: double entry, card clearing, ACH batch files. What is newer is who runs them: software firms that hold or move customer money, often on a partner bank’s licence. That brought retries, races and schema changes into bookkeeping, and regulators followed (safeguarding). We found no documented origin of the label.

flowchart TB
  API["API Ops<br/>API contracts and versions"]:::neutral
  FT["FinTechOps<br/>money moves once,<br/>books reconcile"]:::core
  FC["FinCrimeOps<br/>screening, monitoring,<br/>reports"]:::neutral
  CO["ComplianceOps<br/>control evidence"]:::neutral
  SRE["SRE<br/>SLOs and incidents"]:::neutral
  FIN["Finance<br/>general ledger, close"]:::neutral
  EXT["Banks, processors,<br/>schemes"]:::risk
  API -->|"payment APIs"| FT
  SRE -->|"reliability"| FT
  EXT <-->|"instructions, files"| FT
  FT -->|"payments, events"| FC
  FC -.->|"holds, returns"| FT
  FT -->|"journals"| FIN
  FT -->|"evidence"| CO
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029

Mission. Move customers’ money exactly once, know at every moment whose money is where, and prove it every day.

1. The ledger is the system of record; everything else is a projection. Balances and reports derive from journal entries.
2. Entries are immutable and balanced. Corrections are new entries that reverse or adjust, never updates or deletes.
3. Every money-moving request carries an idempotency key, and the key and its effect commit together.
4. Unknown is a state, not an error. A timeout from a bank or processor means “outcome unknown”; resolve it by enquiry or by the rail’s own report, never by blind retry or blind failure.
5. Reconcile daily against an independent record, and age every break.
6. Card numbers stay out of systems that do not need them.
7. Design for the rail’s finality. Release goods, credit wallets and pay out only when the rail’s risk of reversal is acceptable.

Non-goals. Real-time perfection of every report; zero breaks (breaks are information); building your own ledger when a provider’s fits.

Rails differ in when money is final and how it can come back.

Two operational facts follow. Instant rails remove the safety net: checks must happen before sending. Under the EU’s Instant Payments Regulation, euro-area providers offer verification of payee (VoP) from 9 October 2025 for standard and instant euro credit transfers, returning “match”, “close match”, “no match” or “other”; euro-area payment and e-money institutions must send and receive instant payments by 9 April 2027.^[22] Card holds expire: Stripe documents authorisation windows of five to seven days for online card payments, by brand and by who initiated the payment (October 2026), so a capture after the window can fail.^[23]

ISO 20022 in one table. The message prefix says who talks to whom, which tells reconciliation which file to read:^[24]

This RACI is a proposal (R = responsible, A = accountable, C = consulted, I = informed).

Each payment goes through initiate → authorise or validate → submit to the rail → settle → reconcile → (possibly) return. The platform has its own Day 0/1/2:

• Day 0 (design): rails and processors; chart of accounts and posting rules; customer-visible states; external records to reconcile against.
• Day 1 (launch): simulator tests, then small live amounts; reconciliation from the first live day; compliance sign-off.
• Day 2 (run): daily close, breaks, returns and disputes, rail changes, safeguarding records and regulatory returns.

• Every business day: the daily close: files, reconciliations, breaks, safeguarding position, unknown-outcome payments.
• Weekly: break ageing with owners; returns and disputes trends; capacity for peaks (paydays, sales, month-end).
• Monthly: close with finance; regulatory returns (the UK safeguarding return is due within 15 business days of month end);^[25] review of manual adjustments.
• Per change: posting-rule changes reviewed like schema migrations, with replay tests on yesterday’s events.
• Escalation: a break above a threshold, any safeguarding shortfall or any duplicate payout pages the on-call owner.

flowchart TB
  C["Client apps<br/>with idempotency keys"]:::neutral
  API["Payments API<br/>validation, auth"]:::core
  SM["Payment state<br/>machine"]:::core
  L["Double-entry<br/>ledger"]:::core
  OB["Outbox and<br/>rail adapters"]:::core
  EXT["Processors, banks,<br/>schemes"]:::risk
  FILES["Reports, statements,<br/>webhooks"]:::neutral
  REC["Reconciliation<br/>engine"]:::core
  BRK["Break queue<br/>owners, ageing"]:::decision
  RPT["Safeguarding, finance<br/>and regulatory reports"]:::neutral
  C --> API
  API --> SM
  SM -->|"journal entries"| L
  SM --> OB
  OB -->|"instructions"| EXT
  EXT --> FILES
  FILES -->|"status updates"| SM
  FILES --> REC
  L --> REC
  REC --> BRK
  REC --> RPT
  BRK -. "adjusting entries" .-> L
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029

Design choices that matter more than vendor choice:

Most incidents start in the states between “sent” and “known”. The state machine below makes them explicit.

stateDiagram-v2
  state answer <<choice>>
  [*] --> Created
  Created --> Pending: validated, ledger hold
  Pending --> Submitted: outbox sends
  Submitted --> answer: rail replies
  Submitted --> Unknown: timeout or no reply
  Unknown --> answer: enquiry or rail report
  answer --> Succeeded: confirmed
  answer --> Failed: rejected
  Failed --> [*]: hold released
  Succeeded --> Settled: settlement file
  Settled --> Returned: early return
  Settled --> Reconciled: matched
  Reconciled --> Returned: late return or dispute
  Reconciled --> Final: return windows closed
  Returned --> Final: reversal posted, matched
  Final --> [*]

Happy path. A wallet top-up by card: the API validates the request and key; the ledger records a receivable from the processor and a liability to the customer; the processor confirms; the next day its settlement report and the bank credit match the ledger.

Exception paths:

• Timeout after submission (Unknown). Do not resend a new instruction. Query the status with the same reference, or wait for the rail’s report. In India, the RBI’s turn-around-time framework requires a UPI transfer debited without beneficiary credit to be reversed by the beneficiary bank by T+1, with ₹100 per day compensation beyond that (circular of 20 September 2019; check for later amendments).^[20]
• Rejected after hold. Release the hold with a reversing entry and tell the customer the reason code in plain words.
• Settled, then returned. Post the return as a new entry; if the funds were already paid out, the shortfall becomes a receivable from the customer or a loss.
• Late presentment. Checkout.com’s issuing documentation says a presentment arriving after an issuer reversal is honoured, and the issuer may then raise an “Authorization-Related Chargeback”; ledgers must accept a capture with no live hold.^[9]

sequenceDiagram
  participant M as Merchant
  participant P as Processor
  participant S as Scheme
  participant I as Issuer
  M->>P: Authorise 50.00
  P->>S: Auth request
  S->>I: Auth request
  I->>S: Approved, hold
  S->>P: Approved
  P->>M: Approved
  M->>P: Capture 48.00
  P->>S: Clearing record
  S->>I: Presentment
  I->>S: Settle funds
  S->>P: Settle funds
  P->>M: Net payout and report

The merchant sees three amounts: authorisation (50.00, today), capture (48.00, at shipping) and payout (48.00 minus fees, days later). Reconciliation must link all three.

The charter says what must stay true; these playbooks cover the work that most often goes wrong.

1. The client generates the key and stores it before sending. TigerBeetle’s guidance is that the app or browser, not your API, generates the transfer ID, persists it locally and reuses it on every retry.^[27] A key per business intent (“pay invoice 841 once”), not per HTTP attempt.
2. Record the key and the effect in one transaction. The AWS Builders’ Library warns that recording the token and doing the mutating work must be one atomic (ACID) operation, or you can record the token and fail to act, or act and fail to record it.^[28] In a ledger, the unique key and the journal entry commit together (Lab 1 and Lab 3).
3. Compare the payload on replay: same request, stored result; different request, error. Stripe errors if parameters differ from the original, and its v1 API returns the saved response on retries, “including 500 errors” (as of October 2026).^[29] The IETF Idempotency-Key header draft, still an Internet-Draft (revision 08, 22 October 2026), suggests HTTP 422 for a reused key with a different payload and 409 Conflict for a retry that arrives while the original is still running.^[30]
4. Pass the key downstream. Send the same key or reference to the processor or bank, so their side de-duplicates too. Your idempotency protects your database, not the rail. Providers keep keys only for a time: Stripe v1 keys may be pruned after 24 hours, after which a reused key makes a new request,^[29] so a late retry first queries by your own reference.
5. Keep your keys longer than any retry can arrive (this Atlas’s rule), including offline mobile clients and batch replays; never put personal data in a key.^[29]

Accept when a replay test (same request sent 2, 10 and 100 times, including concurrently) produces one journal entry and one rail instruction.

1. Name accounts by owner and purpose (wallet:<customer>, receivable:psp, bank:safeguarding, expense:psp_fees) and give each a normal side (debit or credit).
2. Write one posting rule per business event before writing code, and review it with finance.
3. Enforce invariants in the database: entries balance; amounts are positive integers in minor units; currency per entry; no updates or deletes on postings.
4. Model money in flight explicitly. A card top-up creates a receivable from the processor until the payout arrives; a pending transfer reserves funds until posted, voided or expired.^[26]
5. Keep one currency per entry; foreign exchange is two balanced legs through an FX account, with the rate stored.

1. List every independent record: processor settlement reports, payout notifications, bank statements (for example ISO 20022 camt notifications; FedNow sends camt.054 debit and credit notifications),^[15] scheme files, partner-bank balances.
2. Reconcile in legs. Ledger ↔ processor (each payment), processor ↔ bank (each payout batch, net of fees and adjustments), ledger ↔ bank (balances). Lab 2 runs all three. On net-settled rails such as UPI the bank movement is one net amount per settlement cycle, so reconcile per cycle.^[18]
3. Classify each break: timing (expected later, often from cut-offs, bank holidays or time zones), amount mismatch, missing on one side, duplicate, unbooked adjustment (chargeback, reserve, fee change).
4. Give every break an owner, a reason code and an age. Timing items need an expected date; once past it, they become breaks.
5. Fix the cause, not only the item. A break class that recurs is a bug or a missing posting rule.
6. Sign off the day: record time, actions and outcome. UK safeguarding rules require exactly that for each safeguarding reconciliation.^[31]

Accept when the day is signed off before the funding deadline, every open break has an owner and expected resolution date, and breaks older than the agreed age are escalated.

Customer money held by a non-bank usually sits in pooled accounts at banks; the firm’s ledger says who owns which share. The ledger is then the only record of each customer’s entitlement, which makes reconciliation a customer-protection control. Rules as of October 2026:

• UK safeguarding institutions (authorised payment and e-money firms, with exceptions; FCA CASS 15, in force 7 May 2026): internal and external safeguarding reconciliations “no less than once each reconciliation day”; the internal one uses the firm’s own records “rather than” bank statements; a shortfall is paid in “by the end of the day on which the reconciliation is performed”; record time, date, actions and outcome.^[31][32] A monthly return goes to the FCA.^[25]
• US bank–fintech arrangements: US regulators noted in 2024 that third parties may maintain “the deposit and transaction system of record”, and that a bank lacking access to it may be unable to determine its deposit obligations, delaying end users’ access.^[33] The FDIC proposed in 2024 that banks reconcile custodial beneficial ownership records “no less frequently than as of the close of business daily”; we found no final rule as of 23 October 2026.^[34] New interagency third-party risk guidance is open for comment until 16 November 2026.^[35]

The control: daily, independent, signed-off reconciliation at the beneficial-owner level.

PCI DSS v4.0.1 has been the active version since PCI DSS v4.0 was retired on 31 December 2024; its future-dated requirements took effect on 31 March 2025 (check the PCI SSC document library for later revisions).^[36][37]

1. Keep card numbers out. Use the processor’s hosted payment page, hosted fields or a tokenisation service, so your systems hold only tokens. The PCI SSC’s tokenisation guidance says that if the merchant can retrieve the card number (PAN), its environment is in scope; the tokenisation system is part of its operator’s cardholder data environment.^[38] If a provider operates it, you manage that provider.
2. Know whether you are a service provider. Storing, processing or transmitting card data “on behalf of another entity” makes you a PCI DSS service provider, with its own validation path.^[39]
3. Map connected systems. Systems with connectivity to the CDE are “connected to” systems and in scope; attackers often enter through systems an entity considered out of scope.^[40]
4. Protect payment pages. Since 31 March 2025, merchants validating with SAQ A must confirm their site is “not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s)”; the payment-page script requirements 6.4.3 and 11.6.1 left SAQ A only, and the PCI SSC says the change does “not remove or diminish the underlying requirements”.^[37]
5. Search logs and support tools for card numbers on a schedule; a PAN in a ticket or log line expands scope.

Audit evidence and the control calendar belong to ComplianceOps.

• Security profile. The OpenID Foundation’s FAPI 2.0 Security Profile (final, 22 February 2025) allows only confidential clients and sender-constrained access tokens, bound with mutual TLS or DPoP.^[41]
• Availability you can prove. UK Open Banking’s operational guidelines (v4.0.1, March 2026) set availability and performance KPIs for banks’ dedicated interfaces, following the EBA Guidelines, and require published statistics.^[42] Third parties should measure the same KPIs from their side.
• Regulation in motion (October 2026). The EU’s PSD3 and Payment Services Regulation (provisional agreement 27 November 2025, ECON approval 5 May 2026) were “close to adoption” on the European Parliament’s tracker in September 2026.^[43] The US CFPB’s personal financial data rights rule (published 18 November 2024) has had its compliance dates stayed by a court since 29 October 2025 while the CFPB reconsiders it.^[44]

Examples verified on 2026-10-23, not recommendations.

Automate matching, break classification, status enquiries and customer messages. Automation is riskiest where it moves money or posts adjustments without a second person: keep four-eyes approval above a threshold. Language models can summarise break histories for an analyst; they should not decide postings. Fraud and AML models belong to FinCrimeOps.

A minimal set for a small wallet or marketplace business (this Atlas’s proposals; adapt names to your rails and licence).

1. Break record, one per unmatched item, in the reconciliation tool.

Example status: syntax-checked (YAML), not executed; fictional data.

break_id: BRK-2026-11-03-0007
reconciliation: processor_to_bank   # or ledger_to_processor, ledger_to_bank
detected_at: 2026-11-03T07:40:00Z
kind: unbooked_adjustment           # timing, amount_mismatch, missing_*, duplicate
external_ref: CB-551
amount_minor: -1000
currency: EUR
explanation: Chargeback on P-0950 deducted from payout PO-77; no ledger entry yet
owner: recon-ops-2
expected_resolution: 2026-11-03
resolution:
  action: post_entry                # or chase_counterparty, write_off, no_action
  journal_ref: J-2026-11-03-1182         # adjusting entry, four-eyes approved
  approved_by: [recon-ops-2, ledger-owner-1]
root_cause: chargeback webhook not mapped to a posting rule
prevention: posting rule CHARGEBACK_V1 added; replay test passed

2. Daily close SOP (one page; times are an example for a UK firm).

DAILY MONEY CLOSE - owner: reconciliation lead; backup: treasury analyst
07:00  Files in? Processor settlement reports, payout notices, bank statements.
       Missing file at 07:30 -> chase counterparty, open incident if past cut-off.
07:30  Run reconciliations: ledger-processor, processor-bank, ledger-bank.
08:30  Triage new breaks: owner, reason code, expected date. Escalate > threshold.
09:00  Unknown-outcome payments older than 1 hour: status enquiry or rail report.
10:00  Safeguarding position: requirement vs resource. Shortfall -> treasury tops
       up from own funds today; record time, actions, outcome.
11:00  Sign-off by reconciliation lead; summary to finance and compliance.

3. Unknown-outcome policy, kept in configuration so engineers and operations read the same rules.

Example status: syntax-checked (JSON), not executed.

{
  "policy": "unknown_outcome_v2",
  "applies_to": ["card_capture", "instant_credit", "ach_origination"],
  "on_timeout": "mark_unknown_and_keep_hold",
  "never": ["resend_with_new_reference", "release_hold_without_rail_answer"],
  "status_enquiry": {
    "first_after_seconds": 30,
    "backoff": "exponential",
    "max_attempts": 8
  },
  "escalate_to_ops_after_minutes": 60,
  "customer_message": "Your payment is being confirmed. You have not been charged twice."
}

The posting-rule table and the daily checklist complete the set.

Three labs on synthetic data: Python 3.8 or later with the standard library (SQLite is built in); no cost, no network, no real accounts. Expected outputs are copied from runs on 2026-10-23 (Python 3.8.10, Ubuntu).

Objective. See balanced entries, safe retries, conflict detection and a safeguarding-style check in one small ledger. Prerequisites. Python 3.8+. Time. 25 minutes.

1. Create a folder: mkdir -p ~/fintech-labs && cd ~/fintech-labs.
2. Save this as ledger.py.

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""Lab 1: a double-entry ledger with idempotent posting (SQLite, stdlib only).
Amounts are integer minor units (cents). All data is invented. Python 3.8+."""
import hashlib
import json
import sqlite3
import sys

SCHEMA = """
CREATE TABLE IF NOT EXISTS account (
  id TEXT PRIMARY KEY,
  normal TEXT NOT NULL CHECK (normal IN ('debit', 'credit')));
CREATE TABLE IF NOT EXISTS journal (
  id INTEGER PRIMARY KEY,
  idem_key TEXT NOT NULL UNIQUE,      -- one business intent, one journal
  request_hash TEXT NOT NULL,
  memo TEXT NOT NULL);
CREATE TABLE IF NOT EXISTS posting (
  journal_id INTEGER NOT NULL REFERENCES journal(id),
  account_id TEXT NOT NULL REFERENCES account(id),
  debit INTEGER NOT NULL DEFAULT 0 CHECK (debit >= 0),
  credit INTEGER NOT NULL DEFAULT 0 CHECK (credit >= 0));
"""

ACCOUNTS = [("bank:safeguarding", "debit"), ("bank:operating", "debit"),
            ("receivable:psp", "debit"), ("expense:psp_fees", "debit"),
            ("wallet:alice", "credit"), ("wallet:bob", "credit"),
            ("equity:own_funds", "credit")]


class Conflict(Exception):
    """Same idempotency key, different request: refuse (HTTP 422 style)."""


def connect(path=":memory:"):
    db = sqlite3.connect(path, isolation_level=None)  # explicit transactions
    db.executescript(SCHEMA)
    db.executemany("INSERT OR IGNORE INTO account VALUES (?, ?)", ACCOUNTS)
    return db


def post(db, idem_key, memo, lines):
    """lines: [(account, debit, credit)]. Returns (journal_id, replayed)."""
    if sum(d for _, d, _ in lines) != sum(c for _, _, c in lines):
        raise ValueError(f"unbalanced entry: {memo}")
    if any(d < 0 or c < 0 or (d == 0) == (c == 0) for _, d, c in lines):
        raise ValueError("each line needs exactly one positive side")
    req = hashlib.sha256(json.dumps([memo, lines]).encode()).hexdigest()
    db.execute("BEGIN IMMEDIATE")
    try:
        row = db.execute("SELECT id, request_hash FROM journal WHERE idem_key = ?",
                         (idem_key,)).fetchone()
        if row:
            db.execute("ROLLBACK")
            if row[1] != req:
                raise Conflict(f"key {idem_key} reused with a different request")
            return row[0], True
        jid = db.execute("INSERT INTO journal (idem_key, request_hash, memo) "
                         "VALUES (?, ?, ?)", (idem_key, req, memo)).lastrowid
        db.executemany("INSERT INTO posting VALUES (?, ?, ?, ?)",
                       [(jid, a, d, c) for a, d, c in lines])
        db.execute("COMMIT")
        return jid, False
    except sqlite3.Error:
        db.execute("ROLLBACK")
        raise


def balances(db):
    q = """SELECT a.id, a.normal, COALESCE(SUM(p.debit), 0), COALESCE(SUM(p.credit), 0)
           FROM account a LEFT JOIN posting p ON p.account_id = a.id
           GROUP BY a.id ORDER BY a.id"""
    for acc, normal, dr, cr in db.execute(q):
        yield acc, (dr - cr) if normal == "debit" else (cr - dr)


def show(db):
    dr, cr = db.execute("SELECT SUM(debit), SUM(credit) FROM posting").fetchone()
    print(f"trial balance: debits={dr} credits={cr} balanced={dr == cr}")
    for acc, bal in balances(db):
        print(f"  {acc:<18} {bal / 100:>9.2f}")


if __name__ == "__main__":
    db = connect()
    print(post(db, "capital-2026-11-01", "Owners fund the operating account",
               [("bank:operating", 50000, 0), ("equity:own_funds", 0, 50000)]))
    print(post(db, "topup-7f3a", "Alice tops up 100.00 by card",
               [("receivable:psp", 10000, 0), ("wallet:alice", 0, 10000)]))
    print(post(db, "settle-2026-11-02", "PSP settles net of 1.80 fee",
               [("bank:safeguarding", 9820, 0), ("expense:psp_fees", 180, 0),
                ("receivable:psp", 0, 10000)]))
    xfer = [("wallet:alice", 2500, 0), ("wallet:bob", 0, 2500)]
    print(post(db, "p2p-91c0", "Alice pays Bob 25.00", xfer))
    print(post(db, "p2p-91c0", "Alice pays Bob 25.00", xfer), "<- client retry")
    try:
        post(db, "p2p-91c0", "Alice pays Bob 25.00",
             [("wallet:alice", 5000, 0), ("wallet:bob", 0, 5000)])
    except Conflict as e:
        print("conflict:", e)
    try:
        post(db, "bad-1", "typo", [("wallet:alice", 100, 0), ("wallet:bob", 0, 10)])
    except ValueError as e:
        print("rejected:", e)
    if "--top-up" in sys.argv:  # treasury moves the fee from the firm's own account
        post(db, "topup-own-2026-11-02", "Own funds cover PSP fee",
             [("bank:safeguarding", 180, 0), ("bank:operating", 0, 180)])
    show(db)
    owed = sum(b for a, b in balances(db) if a.startswith("wallet:"))
    held = dict(balances(db))["bank:safeguarding"]
    print(f"customer money owed {owed / 100:.2f}; held {held / 100:.2f}; "
          f"shortfall {(owed - held) / 100:.2f}")

3. Run it, then run it with the own-funds top-up.

Example status: verified by execution on 2026-10-23.

python3 ledger.py
python3 ledger.py --top-up | grep -E "bank:|owed"

Expected output (first run in full, then the filtered lines of the second run):

(1, False)
(2, False)
(3, False)
(4, False)
(4, True) <- client retry
conflict: key p2p-91c0 reused with a different request
rejected: unbalanced entry: typo
trial balance: debits=72500 credits=72500 balanced=True
  bank:operating        500.00
  bank:safeguarding      98.20
  equity:own_funds      500.00
  expense:psp_fees        1.80
  receivable:psp          0.00
  wallet:alice           75.00
  wallet:bob             25.00
customer money owed 100.00; held 98.20; shortfall 1.80

  bank:operating        498.20
  bank:safeguarding     100.00
customer money owed 100.00; held 100.00; shortfall 0.00

Validation. Journal 1 is the owners’ opening capital in the firm’s operating account. The retry returns journal 4 again with True (replayed), so Alice is charged once. Reusing the key with 50.00 is refused, and an unbalanced entry never reaches the database. Debits equal credits, yet customer money owed (100.00) exceeds money held (98.20): the processor fee was taken from customer funds. A transfer from the operating account closes the gap, as a UK safeguarding shortfall must be closed the same day.^[31]

Troubleshooting. An uncaught Conflict means the two p2p-91c0 calls no longer send identical lines (one was edited). Different balances mean the posting lines changed.

Teardown. Nothing is stored (the database is in memory). Lab 3 removes the folder.

Objective. Reconcile a ledger, a processor settlement report and a bank statement; separate timing from real breaks. Prerequisites. Lab 1 folder. Time. 30 minutes.

1. Save this as recon.py.

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""Lab 2: three-way reconciliation of ledger, PSP settlement report and bank
statement for one business day. Synthetic data; stdlib only (Python 3.8+)."""
import csv
import io
from collections import Counter
from datetime import date

AS_OF = date(2026, 11, 3)

LEDGER = """ref,amount,captured_on
P-1001,5000,2026-11-02
P-1002,12000,2026-11-02
P-1003,2599,2026-11-02
P-1004,7500,2026-11-02
P-1005,4000,2026-11-02
P-1005,4000,2026-11-02
P-1006,9900,2026-11-03
"""
# PSP report: gross, fee, net and the batch the net will be paid in.
PSP = """ref,gross,fee,net,payout_id
P-1001,5000,90,4910,PO-77
P-1002,12000,150,11850,PO-77
P-1003,2599,61,2538,PO-77
P-1004,7000,135,6865,PO-77
P-1006,9900,124,9776,PO-78
P-1007,3000,72,2928,PO-77
"""
# Adjustments deducted from payouts (chargebacks, reserves), per payout batch.
ADJUST = """adj_id,payout_id,amount,reason
CB-551,PO-77,-1000,chargeback on P-0950
"""
PAYOUT_DATES = {"PO-77": date(2026, 11, 3), "PO-78": date(2026, 11, 4)}
BANK = """bank_ref,amount,value_date
PO-77,28091,2026-11-03
"""
BOOKED_ADJUSTMENTS = set()  # adj_ids already posted in the ledger


def rows(text):
    return list(csv.DictReader(io.StringIO(text)))


def reconcile():
    breaks = []
    ledger = rows(LEDGER)
    counts = Counter(r["ref"] for r in ledger)
    for ref, n in counts.items():
        if n > 1:
            breaks.append(("duplicate_in_ledger", ref, f"{n} postings"))
    led = {r["ref"]: int(r["amount"]) for r in ledger}
    psp = {r["ref"]: r for r in rows(PSP)}
    for ref, amt in led.items():
        p = psp.get(ref)
        if p is None:
            breaks.append(("missing_at_psp", ref, f"ledger {amt}"))
        elif int(p["gross"]) != amt:
            breaks.append(("amount_mismatch", ref, f"ledger {amt} psp {p['gross']}"))
    for ref in psp.keys() - led.keys():
        breaks.append(("missing_in_ledger", ref, f"psp gross {psp[ref]['gross']}"))
    # Leg 2: each PSP payout batch against the bank statement.
    payouts = Counter()
    for p in psp.values():
        payouts[p["payout_id"]] += int(p["net"])
    for a in rows(ADJUST):
        payouts[a["payout_id"]] += int(a["amount"])
        if a["adj_id"] not in BOOKED_ADJUSTMENTS:
            breaks.append(("unbooked_adjustment", a["adj_id"], a["reason"]))
    bank = {r["bank_ref"]: int(r["amount"]) for r in rows(BANK)}
    for po, expected in sorted(payouts.items()):
        got = bank.get(po)
        if got is None and PAYOUT_DATES[po] > AS_OF:
            due = PAYOUT_DATES[po]
            breaks.append(("in_transit", po, f"expected {expected} on {due}"))
        elif got is None:
            breaks.append(("payout_not_in_bank", po, f"expected {expected}"))
        elif got != expected:
            breaks.append(("payout_amount_diff", po, f"expected {expected} bank {got}"))
    matched = sum(1 for ref in led if ref in psp and int(psp[ref]["gross"]) == led[ref]
                  and counts[ref] == 1)
    return breaks, matched, len(led)


if __name__ == "__main__":
    breaks, matched, total = reconcile()
    real = [b for b in breaks if b[0] != "in_transit"]
    print(f"as of {AS_OF}: {matched}/{total} ledger refs matched "
          f"({matched / total:.0%}); {len(real)} breaks, "
          f"{len(breaks) - len(real)} in transit")
    for kind, ref, detail in sorted(breaks):
        print(f"  {kind:<20} {ref:<7} {detail}")

2. Run it: python3 recon.py.

Expected output:

as of 2026-11-03: 4/6 ledger refs matched (67%); 5 breaks, 1 in transit
  amount_mismatch      P-1004  ledger 7500 psp 7000
  duplicate_in_ledger  P-1005  2 postings
  in_transit           PO-78   expected 9776 on 2026-11-04
  missing_at_psp       P-1005  ledger 4000
  missing_in_ledger    P-1007  psp gross 3000
  unbooked_adjustment  CB-551  chargeback on P-0950

Validation and interpretation.

• P-1004: ledger 75.00, processor 70.00: an unrecorded partial capture or a wrong amount.
• P-1005: posted twice and unknown to the processor: a retry without idempotency, possibly never captured. Investigate before telling the customer anything.
• P-1007: a processor payment the ledger lacks (lost webhook?); the customer may be owed a credit.
• CB-551: PO-77 matches the bank only after the 10.00 chargeback, which the ledger has not booked.
• PO-78: due tomorrow; timing, not a break, until its date passes.

Troubleshooting. A KeyError in PAYOUT_DATES means a payout ID was added to the data without a date.

Teardown. Lab 3 removes the folder.

Objective. Show why “check the key, then insert” double-pays under concurrency, and how a database unique constraint fixes it. Prerequisites. Lab 1 folder. Time. 20 minutes.

1. Save this as race.py. Two connections replay a fixed interleaving: both read before either writes.

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""Lab 3: two retries of one payment race through check-then-insert.
Two SQLite connections replay a fixed interleaving. Python 3.8+, stdlib."""
import os
import sqlite3
import tempfile


def setup(path, unique):
    db = sqlite3.connect(path, isolation_level=None)
    key = "UNIQUE" if unique else ""
    db.executescript(f"""
      DROP TABLE IF EXISTS payout;
      CREATE TABLE payout (id INTEGER PRIMARY KEY, idem_key TEXT NOT NULL {key},
                           amount INTEGER NOT NULL);""")
    db.close()


def check(db, key):
    """Step 1 of the naive handler: 'have we seen this key?'"""
    return db.execute("SELECT id FROM payout WHERE idem_key = ?", (key,)).fetchone()


def insert(db, key, amount):
    """Step 2: record the payout (and, in real life, call the bank)."""
    try:
        db.execute("BEGIN IMMEDIATE")
        db.execute("INSERT INTO payout (idem_key, amount) VALUES (?, ?)", (key, amount))
        db.execute("COMMIT")
        return "sent payout"
    except sqlite3.IntegrityError:
        db.execute("ROLLBACK")
        return "duplicate refused; return the stored result"


def run(unique):
    path = os.path.join(tempfile.mkdtemp(prefix="race-"), "race.db")
    setup(path, unique)
    a = sqlite3.connect(path, isolation_level=None)
    b = sqlite3.connect(path, isolation_level=None)
    key = "payout-2026-11-03-0042"
    seen_a, seen_b = check(a, key), check(b, key)  # both read before either writes
    print(f"  A sees key: {seen_a is not None}; B sees key: {seen_b is not None}")
    print("  A:", insert(a, key, 50000) if not seen_a else "replay")
    print("  B:", insert(b, key, 50000) if not seen_b else "replay")
    n, total = a.execute("SELECT COUNT(*), SUM(amount) FROM payout").fetchone()
    print(f"  payouts recorded: {n}; money sent: {total / 100:.2f}")
    a.close()
    b.close()
    os.remove(path); os.rmdir(os.path.dirname(path))


if __name__ == "__main__":
    print("naive check-then-insert, no unique constraint:")
    run(unique=False)
    print("same code, UNIQUE(idem_key) enforced by the database:")
    run(unique=True)

2. Run it: python3 race.py.

Expected output:

naive check-then-insert, no unique constraint:
  A sees key: False; B sees key: False
  A: sent payout
  B: sent payout
  payouts recorded: 2; money sent: 1000.00
same code, UNIQUE(idem_key) enforced by the database:
  A sees key: False; B sees key: False
  A: sent payout
  B: duplicate refused; return the stored result
  payouts recorded: 1; money sent: 500.00

Validation. Without the constraint both retries pass the check and two payouts are sent. With UNIQUE(idem_key) the database refuses the second insert, and the handler returns the stored result. In production the rail instruction must be sent only after the insert commits (for example from an outbox), carrying the same key.^[28]

Troubleshooting. database is locked means another program holds the file; the script uses a fresh temporary directory per run.

Teardown. rm -r ~/fintech-labs (the script removes its own temporary database).

The first case applies the sourced Synapse facts; the other two are illustrative. Methods are this Atlas’s proposals.

1. A fintech app on a partner bank’s pooled account (BaaS). Context: customer funds sit in a “for the benefit of” account at a partner bank; the fintech or a middleware provider keeps the per-customer ledger.^[6] Method: one beneficial-owner ledger the bank can read; daily reconciliation of customer balances to the bank balance, signed by both sides; a contract that gives the bank the system of record if the provider fails.^[33] Success: zero unexplained difference at each close. Pitfall: a middleware provider moving funds between several banks with no per-bank reconciliation.

2. Marketplace payouts through a processor (illustrative). Context: a marketplace pays sellers weekly, net of commission. Method: posting rules for gross, fees, commission and seller payable; Lab 2’s reconciliation; a payout reserve sized to the dispute window. Success: payout batches matched on the value date; no seller paid twice. Pitfall: paying sellers on the processor’s “succeeded” event, then absorbing chargebacks.

3. Instant payments around the clock (illustrative). Context: a firm starts sending irrevocable instant credit transfers. Method: verification of payee where offered;^[22] pre-send fraud checks with FinCrimeOps; per-bank success-rate monitoring; an unknown-outcome policy and customer messages before launch. Success: per-bank success rate and unknown-state age within target, every hour. Pitfall: letting the customer resend after a timeout.

Uptime hides partial degradation. NPCI reports UPI at 100% for most months to August 2025, and April 2025 at 99.72%: about 121 minutes of a 30-day month, while its downtime table lists 300 minutes marked “Partial & Intermittent”, at 50% and 80% success rates.^[52] Measure exactness and success as well as uptime. Formulas are this Atlas’s.

Review exactness daily, success rates continuously, trends weekly; set targets from your own baseline.

• Card data: PCI DSS scope reduction (playbook); no card numbers in logs, tickets or analytics.
• Least privilege on money: separate roles for initiating, approving and posting manual adjustments and payouts; log every change to posting rules and bank details.
• Incident duties (as of October 2026): US banks notify their regulator “no later than 36 hours” after determining a notification incident occurred, and their service providers must tell affected banks “as soon as possible” about disruptions of four or more hours;^[47] the UK FCA’s operational resilience rules apply to payment and e-money firms;^[45] EU DORA applies to financial entities from 17 January 2025, including reporting of major ICT incidents.^[46]
• Privacy: ledgers hold personal data for years; retention and access rules come from PrivacyOps and national law.

The main costs are processor and scheme fees, people working breaks, and losses (duplicates, unrecovered returns, chargebacks). Plan capacity for peaks and cut-offs: paydays, sale days, month-end, and the fixed windows of batch rails. Illustrative model: 1,180 manual items a day at 4 minutes each is about 79 hours, roughly ten analysts; raising auto-match from 99.0% to 99.5% halves that. Fixing recurring break classes is the cheaper lever.

Monthly second-line review of sampled sign-offs; internal audit of posting-rule changes and manual entries; hourly canary payments (small real payments on each rail); alerts on missing, duplicated or out-of-sequence files; and a quarterly replay of a historic day through current posting rules.

1. Stop the bleeding (minute 0–15). Pause the payout job and its retries; declare an incident; name a lead and a ledger owner.
2. Bound the damage (15–60). Compare payouts created since 16:00 with the processor’s payout list; classify each as sent once, sent twice or unknown.
3. Resolve the unknowns (1–3 hours). Query the processor by your reference; resend nothing until every item is known.
4. Correct the books (same day). Post duplicates as receivables from the sellers (four-eyes). If a safeguarding account paid them, top it up from own funds and record it.^[31]
5. Recover (days 1–5). Ask sellers to return funds or net them against the next payout under your terms; log every contact.
6. Prevent (week 1). Root cause: the retry generated a new key. Fix: one key per payout intent, stored before the first call and sent to the processor; a timeout replay test; an alert on two payouts per seller per cycle.

Exit criteria: every payout in the window classified and reconciled; books and safeguarding position correct; root-cause fix tested; postmortem done using the IncidentOps process.

flowchart TB
  A["Daily reconciliation"]:::core --> B{"Matched?"}:::decision
  B -->|"yes"| Z["Sign off the day"]:::core
  B -->|"no"| C{"Timing item<br/>before due date?"}:::decision
  C -->|"yes"| W["Track with<br/>expected date"]:::neutral
  W --> A
  C -->|"no"| D["Break record:<br/>owner, reason, age"]:::risk
  D --> E{"Money missing or<br/>customer harmed?"}:::decision
  E -->|"yes"| F["Incident; top up or<br/>refund today"]:::risk
  E -->|"no"| G["Investigate with<br/>counterparty"]:::neutral
  F --> H["Adjusting entry,<br/>four-eyes"]:::core
  G --> H
  H --> I["Root cause and<br/>posting-rule fix"]:::core
  I --> A
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029

• “We can fix the balance with an UPDATE.” It destroys the audit trail; post an entry instead.
• “Retries are safe; the processor is idempotent.” Only if you send the same key; a new key is a new payment.
• “Reconciliation is finance’s month-end job.” Daily differences become unexplainable monthly ones.

Run these practices as a named function when you hold or move other people’s money: wallets, marketplaces, payroll, lending disbursement, card issuing, or any product on a partner bank’s licence. Signals: more than one rail or processor, pooled customer accounts, or a regulator or partner bank asking for daily reconciliation.

Do not build your own ledger and rail integrations when a provider’s hosted product covers your flows with per-payment reports; operate theirs well. And do not start with tooling when the problem is ownership: a named owner of the daily close comes first.

flowchart TB
  A{"Do you hold customer<br/>balances or pooled funds?"}:::decision
  A -->|"no: accept<br/>payments only"| B["Use processor<br/>reports"]:::neutral
  A -->|"yes"| C{"Provider ledger with<br/>per-customer records<br/>you and bank can read?"}:::decision
  C -->|"yes"| D["Operate the provider's ledger;<br/>reconcile it daily"]:::core
  C -->|"no"| E{"Team able to run<br/>ledger invariants<br/>and on-call?"}:::decision
  E -->|"no"| F["Change provider or<br/>hire before launch"]:::risk
  E -->|"yes"| G["Own the ledger;<br/>buy rails and matching"]:::core
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029

This is this Atlas’s simplification; licensing and safeguarding duties are legal questions for each jurisdiction.

This is this Atlas’s model, not an industry standard.

For a new head of payment operations at a growing fintech:

• Days 1–30: see the money. Inventory rails, processors, bank accounts and files; draw the three views for each product; find every place a balance can be edited. Quick win: a daily ledger-to-bank balance check with an owner.
• Days 31–60: make it exact. Posting rules reviewed with finance; idempotency keys stored with entries; unknown-outcome policy; break records with reason codes. Milestone: no unowned breaks.
• Days 61–90: make it provable. Three-way reconciliation signed off daily; safeguarding records and returns; concurrency and timeout tests in CI; per-bank success-rate alerts. Milestone: first month with the duplicate rate and break age on target.

Launch readiness (new rail, processor or product)

• Posting rules for every event, including returns, disputes, fees and reversals, reviewed by finance
• Idempotency keys end to end, including the processor call; concurrency and timeout tests pass
• Reconciliation runs from day one; reports give per-payment fees and adjustments
• Unknown-outcome policy and customer messages approved; card numbers never reach your systems

Daily close

• All expected files received, in sequence, once
• Three-way reconciliation run; new breaks owned; timing items dated
• Unknown-outcome payments resolved or escalated; safeguarding gap closed and recorded

Monthly governance

• Manual adjustments reviewed by a second line; posting-rule changes audited
• Regulatory returns filed; PCI DSS scope re-checked (logs, tickets, page scripts)

Posting-rule change request (lines ≤ 90 characters):

RULE: CHARGEBACK_V1            OWNER: ledger owner        STATUS: proposed
EVENT: processor adjustment, type=chargeback
ENTRY: Dr wallet:<customer> (or receivable:customer if wallet < amount)
       Cr receivable:psp
INVARIANTS: balanced; one entry per adjustment id (idempotency key = adj_id)
TESTS: replay 2026-11-03 events; duplicate adjustment ignored; empty wallet case
APPROVALS: finance, reconciliation lead      ROLLBACK: disable rule, re-run day

Break reason codes: T01 timing; A01 amount mismatch; M01 missing in ledger; M02 missing externally; D01 duplicate; J01 unbooked adjustment; F01 fee difference. “Other” above 5% of breaks means the list is wrong.

Operating models (this Atlas’s comparison):

Do we need a ledger if our processor keeps balances? If you hold customer balances or pooled funds, yes, or a provider ledger that you and your bank can read; otherwise the processor’s reports may be enough (decision).

Can we retry a payment that timed out? Only with the same idempotency key and reference; better, ask the rail for its status first.

Does tokenisation remove PCI DSS duties? It reduces scope; duties remain for connected systems, payment pages and, if you operate it, the tokenisation system; if a provider operates it, you manage that provider.^[38][40]

How often must we reconcile? It depends on licence and jurisdiction; UK safeguarding firms at least once each reconciliation day;^[31] this Atlas recommends daily for anyone holding customer money.

Who owns a break caused by the partner bank? You do, until it is closed: the customer sees your app.

• ISO 20022 everywhere (established). Cross-border payment instructions moved to ISO 20022 in November 2025,^[21] and FedNow uses pacs messages;^[15] richer structured data makes automatic matching easier.
• Ledger databases (active engineering). Purpose-built stores record each transfer as one debit and one credit, with the transfer ID as its idempotency key.^[11]
• Exceptions as messages (established, FedNow). A return request “should be sent within 60 calendar days” of settlement, and the same messages report fraud (codes FRAD, FR01).^[16] Post them as ledger events.

• Prerequisites: API Ops (APIs, transactions); WorkflowOps (retries, sagas).
• Day 1: glossary; Lab 1. Week 1: your processor’s settlement report; Labs 2 and 3; your rail’s return codes.
• Month 1: shadow a daily close; write posting rules for one product; run a timeout game day.
• Specialise: ledgers, rail integrations or reconciliation. Portfolio: a ledger with replay tests and a synthetic three-way reconciliation.

Option A: launch on the date. Revenue sooner, but instant credits are irrevocable,^[15] so every duplicate is a loss to recover from a seller.

Option B: first add one key per payout intent, an outbox and timeout tests (about four weeks). A week late; duplicates prevented.

Assumptions that decide it: how often timeouts happen; the average payout; whether your terms let you recover from sellers. Reasoned choice: B, or A limited to small payouts with a daily cap. Uncertainty: if timeouts are truly rare, A’s expected loss may be small, so measure first.

You can now explain the label’s status, design posting rules, make money movement idempotent, reconcile in three legs, and choose controls by rail finality.

“FinTechOps” is not a discipline anyone standardised, but the work behind it is old and exact: double entry, settlement finality and reconciliation, now run by software teams at API speed. Synapse and TSB show two ways it fails: books that drift from the bank, and changes that break banking services. Hold the cheat sheet’s invariants, and have someone sign the daily reconciliation.

All sources opened 2026-10-23; “archived copy” = Internet Archive copy, read because the live site blocked automated access.

Changelog

• 2026-10-23, r0: first draft (research, evidence ledger, three executed labs, six diagrams). Not yet independently fact-checked.
• 2026-10-23, r1: after independent fact check: UPI shown as net-settled; state machine allows late returns after reconciliation; VoP, CASS scope, late presentment, PCI service providers, key pruning, ISO 20022 families corrected or added; Lab 1 re-run.
• 2026-10-23, r2: FedNow returns sourced; FCA operational-resilience dates; TigerBeetle wording; one advanced topic; repeats trimmed.
• 2026-10-23, post-score polish: FedNow return routes; second R10 source; Stripe windows by initiator; early-return edge in the state machine; repeats trimmed.