Python in Fintech

Every fintech product I have seen built in this region ends up with Python somewhere in it. Sometimes it is the whole backend. Sometimes it is a reconciliation script a finance analyst wrote one evening that, two years later, settles merchant payouts every night. Sometimes it is the fraud model, the warehouse jobs, or the notebook that answers the regulator's question an hour before the deadline.

That ubiquity is both the argument for Python and the warning about it. The language is easy to start with and surprisingly hard to run well when money is on the line. This is what I wish every founder and engineering lead knew before choosing Python for a payments, lending, wallet or trading product in MENA. It is not a tutorial; the subject is the ecosystem: where it fits, where it does not, and how to decide.

Why Python matters in fintech

The money-adjacent layer is where Python lives

Fintech systems have a small core that moves money and a much larger surrounding layer that decides whether, when and how it should move. The core is a ledger, a payment orchestration service and a settlement job. The surrounding layer is everything else: onboarding and KYC, risk scoring, limits, pricing, fraud detection, reconciliation, regulatory reporting, dashboards and the data pipelines that feed them all.

Python dominates that surrounding layer. It is the language of data science, of scripting, of glue, and of the frameworks (Django, FastAPI, Flask) that let a small team ship a regulated product in months rather than years. Even where the core is Java, Go or Rust, the risk models, the reconciliation tooling and the analytics stack are usually Python. It is not the language for a matching engine, though. The honest case for Python in fintech is a case for Python in most of the system, not all of it.

The question in practice is rarely "Python or not". It is "how much of the system should be Python, and where exactly do we draw the line".

Why the question is sharper in MENA

Three things make this region different from the markets most Python advice is written for.

First, regulatory velocity. SAMA in Saudi Arabia, the CBUAE in the Emirates and the CBE in Egypt have all introduced licensing regimes, instant payment rails and open banking frameworks within a few years of each other. A stack that lets you change a limit, a fee schedule or a reporting format in a day, with tests, has a real advantage.

Second, the integration surface. A wallet in Egypt talks to Meeza, to InstaPay through a bank partner, to Fawry for cash-in, to a card acquirer and to the mobile operators; a Saudi product talks to mada, SADAD, SARIE and an open banking aggregator. None of it is glamorous; all of it is I/O-bound, schema-heavy and changes often, which is exactly what Python is good at.

Third, talent. Egypt graduates a large number of engineers every year who learned Python at university, and the same is increasingly true in Saudi Arabia and the UAE through bootcamps and national programmes. If you want a team you can actually hire in Cairo, Riyadh or Dubai, Python is one of the safest bets.

Where it is used

Everything in this section is publicly documented usage; nothing is invented.

Payments and merchant integrations

Stripe maintains an official Python library, stripe-python, and much of its documentation is in Python; Adyen, Checkout.com and most global PSPs publish Python SDKs or samples. Regionally, Fawry, Paymob, Tap, HyperPay, Moyasar and the bank gateways expose REST APIs that teams wrap in a few hundred lines of httpx code: a thin adapter per provider behind a common interface.

Brokerage, trading and wealth

Robinhood's engineers have spoken publicly about running their backend on Python and Django for years before splitting pieces out. Quantitative finance used Python long before "fintech" was a word: pandas was born inside a hedge fund, NumPy underpins nearly every pricing and backtesting library, and quant desks still prototype in notebooks and port only the hot paths to C++ or Rust. The robo-advisory and trading apps licensed in the Gulf tend to follow the same shape: Python for everything except order routing.

Risk, fraud and data platforms

Here Python has no serious competitor: scikit-learn for the first fraud model, gradient-boosted trees for the second, PyTorch for sequence models over transaction histories. Apache Airflow, written in Python and originally built at Airbnb, schedules the nightly jobs in a large share of fintech data platforms; dbt, Prefect and Dagster are Python too. Netflix has written at length about how deeply Python runs through its data tooling, and the same shape, Python orchestration around a columnar warehouse, is what most lending and payments companies end up with.

Web backends and back office

Instagram has run on Django since its first day and has described publicly how it scaled that to hundreds of millions of users; Dropbox was built on Python and later published the story of type-checking millions of lines of it with mypy. Neither is a fintech, but they are the existence proof that "Python cannot scale" is an objection about architecture, not the language. On the accounting side, Odoo and ERPNext, two widely deployed open-source ERP suites, are written in Python, and many regional back offices run their general ledger and payroll on one of them.

Strengths

Iteration speed where the rules change weekly

A fee schedule changes. A regulator asks for a new field in the monthly report. A partner bank changes a status code. In fintech the product is mostly rules, and rules churn. Python's strength is the short distance between "we agreed the change in the meeting" and "it is live and tested"; a senior engineer can usually land a well-tested business-rule change in hours.

The data ecosystem is the moat

Any serious fintech becomes a data company within a year or two of launch. Credit decisions, fraud, pricing, collections and regulatory reporting all run on the same handful of Python libraries, and the people you hire already know them. Using Python for the application layer means the model a data scientist trained in a notebook can be wrapped, tested and deployed with the same tools, and the gap between research and production that kills so many ML projects is much narrower.

Readability is a compliance feature

Auditors, risk committees and sometimes the regulator's own technical staff will read your code, or at least the parts that calculate interest, fees and limits. Python reads closer to the specification than most languages; a fee calculation written with Decimal and clear names can be reviewed by a finance person who has never written code. That matters when a bank partner asks why their settlement report is off by one piastre.

The standard library pulls its weight

Three pieces of the standard library matter more in fintech than anywhere else. decimal gives you exact, explicitly rounded arithmetic. dataclasses with frozen=True give you immutable value objects almost for free. The typing module, with mypy or pyright in CI, checks the shape of a payment request before production. Add uuid, hmac, secrets and logging, and you can build a surprising amount of a payments service without a single third-party package.

Risks and pitfalls

Floating point and the cost of a rounding error

The first bug in every fintech codebase is the same: someone stored or computed money as a float. It passes every test with round numbers and then, in production, a 2.75% fee on 10.01 yields a net that does not add back up to the gross. Multiply by a few hundred thousand transactions and finance is reconciling by hand on a weekend.

The fix is not "be careful". The fix is a representation that makes the wrong thing impossible: store money as integer minor units or as Decimal, and round exactly once, at a known place, with a named rounding mode. Banker's rounding (ROUND_HALF_EVEN) is the usual default for fee splits because it does not systematically favour either side; some tax calculations mandate ROUND_HALF_UP instead, and you should be able to point to the rule that says so.

Money math with Decimal and explicit rounding

from decimal import Decimal, ROUND_HALF_EVEN

CENTS = Decimal("0.01")


def to_money(value: str | int | Decimal, places: Decimal = CENTS) -> Decimal:
    """Turn an exact string, int or Decimal into a rounded money amount.

    Floats are rejected on purpose: Decimal(0.1) carries binary noise.

    >>> to_money("19.995")
    Decimal('20.00')
    >>> to_money("19.985")
    Decimal('19.98')
    >>> to_money(0.1)
    Traceback (most recent call last):
        ...
    TypeError: pass money as str, int or Decimal, never float
    """
    if isinstance(value, float):
        raise TypeError("pass money as str, int or Decimal, never float")
    return Decimal(value).quantize(places, rounding=ROUND_HALF_EVEN)


def split_fee(amount: Decimal, fee_rate: Decimal) -> tuple[Decimal, Decimal]:
    """Return (fee, net) such that fee + net == amount, always.

    >>> split_fee(to_money("100.00"), Decimal("0.0275"))
    (Decimal('2.75'), Decimal('97.25'))
    >>> fee, net = split_fee(to_money("10.01"), Decimal("0.0275"))
    >>> fee + net == Decimal("10.01")
    True
    """
    fee = to_money(amount * fee_rate)
    net = amount - fee  # derive the remainder; never round twice
    return fee, net


if __name__ == "__main__":
    import doctest

    doctest.testmod()
    print(to_money("0.1") + to_money("0.2"))  # 0.30, not 0.30000000000000004

Tested with Python 3.12.

Floats are rejected at the boundary rather than silently converted, and split_fee rounds the fee and derives the net by subtraction; rounding both sides independently is how you get a one-cent hole nobody can find.

Dynamic typing at the boundaries

Inside a module, dynamic typing is a productivity tool. At the boundaries, where JSON from a partner bank becomes an object in your system, it is a liability: a status field that was an integer last month and a string this month will fail three services later in a way that looks like a business bug. Validate every inbound payload against an explicit schema (pydantic, attrs or dataclasses with checks) and treat unknown fields as errors, not noise.

The notebook that became production

Every data team has one: a notebook that computed a risk score, was wired to a cron job "just for now", and now decides who gets a loan, with no test, no version, no review, and an author who has left. Python makes this failure unusually easy because the same language runs in the notebook and on the server. Draw the line explicitly: notebooks are for exploration; anything that touches a customer's money is a package, with tests, in the pipeline.

Architecture and integration patterns

Modular monolith first

Most regional fintech startups lack the operational maturity for a microservice fleet on day one. Python makes a modular monolith easy: one deployable, packages with clear interfaces, one database with strict schemas. Only payment orchestration, the ledger and the fraud scorer tend to earn their own service.

Idempotency everywhere money moves

Networks fail, clients retry, mobile apps resend. The only safe assumption is that every request to move money will arrive at least twice. An idempotency key, supplied by the caller and stored with the result, turns a duplicate into a harmless replay. The handler below is framework-free; in production the store is a unique index in PostgreSQL or a Redis key with a TTL, and the key is forwarded to the PSP so that they deduplicate too.

An idempotent payment handler

from dataclasses import dataclass
from typing import Callable


@dataclass(frozen=True)
class PaymentResult:
    key: str
    status: str  # "captured" | "failed"
    provider_ref: str | None = None


class InFlight(Exception):
    """The same key is being processed right now; retry after a short delay."""


class DedupeStore:  # production: a unique index in PostgreSQL, or Redis SET NX with a TTL
    def __init__(self) -> None:
        self._rows: dict[str, PaymentResult | None] = {}  # None marks "in flight"

    def claim(self, key: str) -> bool:
        if key in self._rows:
            return False
        self._rows[key] = None
        return True

    def get(self, key: str) -> PaymentResult | None:
        return self._rows.get(key)

    def put(self, key: str, result: PaymentResult) -> None:
        self._rows[key] = result

    def release(self, key: str) -> None:
        self._rows.pop(key, None)


def handle_payment(key: str, charge: Callable[[str], str], store: DedupeStore) -> PaymentResult:
    if (done := store.get(key)) is not None:
        return done  # replay: same answer, money moved once
    if not store.claim(key):
        raise InFlight(key)  # concurrent duplicate: answer 409, never charge twice
    try:
        provider_ref = charge(key)  # forward the key so the provider dedupes as well
    except TimeoutError:
        store.release(key)  # outcome unknown: the client may retry with the same key
        raise
    except Exception:
        result = PaymentResult(key, "failed")
    else:
        result = PaymentResult(key, "captured", provider_ref)
    store.put(key, result)  # failures are final too; a new attempt needs a new key
    return result

Tested with Python 3.12.

The important branches are the unusual ones. A timeout means the outcome is unknown, so the claim is released and the client may retry with the same key; because the key reached the provider too, the retry cannot double-charge. A deterministic failure is stored as final, a concurrent duplicate gets an in-flight error, and a replay after success returns the original result without touching the provider.

Double-entry ledger as the system of record

Balances are not stored; they are derived. That single sentence saves more fintech companies than any other architectural rule. A double-entry ledger records every movement as an entry whose debit and credit lines must balance, entries are immutable, and corrections are new entries. Balances are computed from lines and cached carefully, with the cache always rebuildable. The example below is minimal on purpose: no database, no accounts table, just the invariant.

A minimal double-entry ledger posting

from dataclasses import dataclass, field
from datetime import datetime, timezone
from decimal import Decimal
from uuid import UUID, uuid4


class UnbalancedEntry(ValueError): pass


@dataclass(frozen=True, slots=True)
class Line:
    account: str  # e.g. "assets:psp_receivable", "liabilities:wallet:u123"
    debit: Decimal = Decimal("0")
    credit: Decimal = Decimal("0")

    def __post_init__(self) -> None:
        if self.debit < 0 or self.credit < 0:
            raise ValueError("amounts are non-negative; flip the side instead")
        if (self.debit > 0) == (self.credit > 0):
            raise ValueError("a line is a debit or a credit, never both or neither")


@dataclass(frozen=True, slots=True)
class Entry:
    """A balanced, immutable journal entry. Corrections are new entries, never edits."""
    description: str
    lines: tuple[Line, ...]
    currency: str = "EGP"
    id: UUID = field(default_factory=uuid4)
    posted_at: datetime = field(default_factory=lambda: datetime.now(timezone.utc))

    def __post_init__(self) -> None:
        if len(self.lines) < 2:
            raise UnbalancedEntry("an entry needs at least two lines")
        debits = sum((line.debit for line in self.lines), Decimal("0"))
        credits = sum((line.credit for line in self.lines), Decimal("0"))
        if debits != credits:
            raise UnbalancedEntry(f"debits {debits} != credits {credits}")


if __name__ == "__main__":
    topup = Entry(
        "Card top-up: 100.00 gross, 2.75 PSP fee",
        (
            Line("assets:psp_receivable", debit=Decimal("97.25")),
            Line("expenses:psp_fees", debit=Decimal("2.75")),
            Line("liabilities:wallet:u123", credit=Decimal("100.00")),
        ),
    )
    print(topup.id, "posted", len(topup.lines), "lines")
    try:
        Entry("broken", (Line("assets:cash", debit=Decimal("10")), Line("income:fees", credit=Decimal("9"))))
    except UnbalancedEntry as exc:
        print("rejected:", exc)

Tested with Python 3.12.

In a real system this maps onto two PostgreSQL tables, entries and lines, with a constraint enforcing the same balance invariant, NUMERIC columns read back as Decimal, and no UPDATE or DELETE privilege on either table for the application role. Python enforces the rule first; the database enforces it last.

Outbox, queues and reconciliation

Three more patterns come up in every Python fintech backend I have worked on. The transactional outbox: write the business change and an "event to send" row in the same transaction and let a worker publish it, so the ledger never says "paid" while the webhook silently never went out. Queues for anything slow: notifications, KYC calls and statement generation go through Celery, Dramatiq, RQ or arq with retries and dead-letter queues, never inside a request handler. Daily reconciliation: a job pulls each provider's settlement file and compares it line by line with the ledger; differences are tickets, not silent adjustments.

Integrating with regional PSPs and banks

Many regional integrations still involve SFTP drops of CSV files, SOAP endpoints, callbacks that arrive out of order, and signature schemes documented in a PDF. Python handles all of it: paramiko for SFTP, zeep for SOAP, hmac for signatures, csv and decimal for the files. Wrap each provider in an adapter behind one interface, log every raw exchange with secrets redacted, and assume every callback may be replayed.

A payments integration is not finished when the happy path works. It is finished when a duplicate callback, a late callback and a missing callback all leave the ledger correct.

Security and compliance

The frameworks you will be measured against

If you touch card data, PCI DSS applies, and the most useful architectural decision is to keep your Python services out of scope by never letting a primary account number touch them: tokenise at the edge with the PSP's hosted fields or SDK. SAMA's cybersecurity and outsourcing frameworks in Saudi Arabia, the CBUAE's regulations in the UAE (with separate regimes in DIFC and ADGM) and the CBE's licensing rules in Egypt shape where you host, how you log and how you manage third parties. Open banking, following the PSD2 model in Europe and the local frameworks in the Gulf, adds consent management and API security standards on top.

None of these mandate a language. All of them produce evidence requests, and a Python codebase that is readable, typed, tested and logged makes those requests cheaper to answer.

Secrets management

Secrets do not live in settings.py, in .env files committed "temporarily", or in environment variables every process on the box can read. They live in a secrets manager (the cloud provider's, or HashiCorp Vault), are fetched at start-up by a short, audited piece of code, and they rotate on a runbook written before the first incident. Python-specific traps: print() debugging that leaks a key into logs, repr() of a settings object in an exception report, and a __str__ that includes the token.

Dependency supply chain

This is where Python teams are most often weaker than they believe.

• Pin everything, with hashes. Use a lockfile from Poetry, uv, pip-tools or the standardised pylock.toml of PEP 751, and install in production with --require-hashes or the equivalent.
• Audit continuously. pip-audit and the scanners built into GitHub, GitLab and cloud registries catch known-vulnerable versions; run them in CI and on a schedule, because new advisories land against old lockfiles.
• Produce an SBOM. Regulators and bank partners increasingly ask for a software bill of materials, and CycloneDX tooling makes it cheap once the lockfile is honest.
• Use a private index or proxy that serves only allow-listed packages; typosquatting on PyPI is real.
• Keep the critical path thin: the code that signs PSP requests and calculates money should depend on as little as possible outside the standard library.

PII handling and data residency

Fintech data is almost all personal data: names, national IDs, phone numbers, transaction histories. Classify it, encrypt it at rest with keys you control and in transit everywhere, and minimise it; a reconciliation job rarely needs the customer's name. Mask it in logs and non-production environments; the logging filter that redacts anything that looks like a card number or a national ID belongs in the first week's commits.

Data residency is a first-order architectural decision here. Regulators in Saudi Arabia and the UAE have localisation expectations for financial data in many circumstances, and Egypt's data protection regime restricts cross-border transfers; confirm the specifics with counsel. Your services, queues, databases and backups all need a region you can point to, and a global SaaS for error tracking may be a finding if the stack traces contain PII.

Audit logs

An audit log answers "who changed what, when, from where, and what did it look like before". It is append-only, separate from application logs, structured as JSON, and records both actor and subject. Implement it as one function called from the service layer, not scattered logger.info lines, and ship it to a store the application role cannot modify. The immutability of the ledger and of the audit log are the two properties an examiner tests first.

Performance and scaling

The GIL, honestly

CPython's global interpreter lock means one thread executes Python bytecode at a time per process. For the typical fintech workload this matters less than people fear, because that workload is waiting on PostgreSQL, a PSP, a KYC provider or Redis, and threads release the GIL while they wait. It does matter for CPU-bound work in pure Python: scoring a model row by row, parsing a large file, serialising big responses.

The landscape is changing. PEP 703 made a free-threaded build of CPython possible, and it has shipped as an optional build since Python 3.13. It is not the default and many C extensions are still catching up, so I would not run a payments service on it today; but the "Python can't use my cores" argument now has an expiry date.

asyncio and the worker models

There are three sane deployment models and most teams use at least two. Synchronous workers (Gunicorn with several processes) are simple, predictable and still right for Django apps dominated by database queries. Asynchronous workers (Uvicorn with FastAPI or async Django) built on asyncio shine when a request fans out to several external calls; the trap is one blocking call stalling the event loop. Background workers (Celery, Dramatiq, RQ, arq) take everything that need not happen inside the request and double as back-pressure: when the KYC provider slows down, the queue grows and the API stays up. Monitor queue depth and age, and make every task idempotent, because the broker will deliver some twice.

Multiple processes, not threads, are how you use multiple cores in CPython; run several workers per container or several containers per node.

PostgreSQL connection pooling

Every Python process holds its own database connections, and with async workers a single process can open many; without a pool you will exhaust PostgreSQL's connection limit long before its CPU. Run PgBouncer (or the cloud provider's equivalent) in transaction mode in front of the database, size application-side pools conservatively, and keep transactions short: no PSP call inside an open transaction, ever. psycopg 3 and asyncpg both offer pools; Django's persistent connections plus PgBouncer is the usual combination.

Escape hatches: PyPy, Cython and Rust

When a hot path really is CPU-bound, you have options before rewriting the service. Vectorise with NumPy or pandas, or move the computation into SQL; this fixes most reconciliation and reporting jobs. Use Cython or a C extension for a tight loop. Write a Rust extension through PyO3 and maturin: pydantic's core, polars, ruff and uv are all Rust under a Python surface, and a small Rust module for a signature check or a parser is now routine. PyPy, a JIT-compiled interpreter, can speed up pure-Python workloads, but C-extension compatibility and operational unfamiliarity make it a niche choice for regulated services.

Where Python is a poor fit

I would not choose Python for an exchange's matching engine, a market-data feed handler, a risk gate that must answer in microseconds, an HSM or card-terminal layer with hard latency budgets, or anything where predictable tail latency under CPU load is the product. Those belong in Rust, Go, C++ or Java, and a Python shop should be comfortable building a small service in another language when the workload demands it.

Workload	Python fit	Notes
APIs for apps and merchants	Excellent	I/O-bound; async or multi-process
Payment orchestration, PSP adapters	Excellent	Idempotency matters more than speed
Ledger service on PostgreSQL	Good	The database does the heavy lifting
Fraud scoring (batch)	Excellent	NumPy, pandas, model libraries
Fraud scoring (sub-10 ms online)	Fair	Serve models from a compiled runtime
Reconciliation, reporting	Excellent	pandas or SQL
Matching engine, HFT	Poor	Rust, C++ or Java
Hard real-time device integration	Poor	Not a fit

Team and hiring in MENA

Talent availability

Egypt is the deepest Python market in the region by headcount: large university output, a long history of outsourcing and offshore engineering centres, and a cost base that makes it the natural place to build a backend team. Saudi Arabia has a smaller but fast-growing pool, supported by national programmes and the fintech licences SAMA has issued; demand outstrips supply, and Saudi nationals with payments experience are highly sought after. The UAE is the hub for senior and leadership talent, much of it expatriate. A common shape is product and leadership in Riyadh or Dubai with most of engineering in Cairo.

Remote and distributed teams

Time zones across the three countries differ by at most two hours, which makes a distributed team practical. The hard parts are not technical: weekends differ (Friday and Saturday in Egypt and Saudi Arabia; Saturday and Sunday in the UAE since 2022), public holidays differ, and a payments on-call rota has to cover all of them. Write the on-call policy before the first incident, and pay for it.

Interview signals that matter for fintech

The signals I weight most heavily, in order:

1. Can they explain, unprompted, why money is not a float and what Decimal rounding modes mean? This one question separates people who have worked near money from people who have not.
2. Do they reach for idempotency and transactions when asked to design a "send money" endpoint, or do they start with the URL scheme?
3. Have they lived with a type checker, a lockfile and a CI pipeline?
4. Can they read a PostgreSQL EXPLAIN plan and reason about a connection pool?
5. Do they understand that logs may contain PII and that a print() in production is a security bug?

Framework trivia (Django versus FastAPI versus Flask) is a weak signal; anyone with the five above will learn a framework in a fortnight.

Upskilling an existing team

Many regional teams come from PHP, Java or .NET, or from data science rather than engineering, and the transition to production Python is faster than the reverse. The highest-leverage investments, in my experience, are a strict type checker in CI, a review culture that treats money-handling code as a different class of change, and a short internal course on Decimal, idempotency and double entry.

Decision framework

Choose Python when

• The product is mostly rules and integrations: wallets, merchant payments, lending, BNPL, remittances, onboarding, back office.
• You will have a data or risk team within a year and want one language from notebook to production.
• You need to ship a licensed product under regulatory deadlines with a team you can hire locally.
• Your performance constraint is the database or third parties, not CPU.

Avoid Python, or isolate it, when

• The product is an exchange, a market-data system or anything with microsecond latency budgets.
• You need predictable tail latency under CPU load, such as an online fraud gate with a hard single-digit-millisecond budget.
• Your senior engineers are all deeply experienced in another ecosystem and you plan to grow around them.
• A hardware or device integration layer dominates the system.

Decision matrix

Score each row from 1 (poor) to 5 (excellent) for your own situation; the scores below are an illustrative estimate for a typical regional payments product, not a benchmark.

Criterion	Python	Go	Java or Kotlin	PHP (Laravel)	Node.js (TypeScript)
Time to a licensed MVP	5	3	3	5	4
Data, risk and ML integration	5	2	3	1	2
Raw throughput per core	2	5	4	2	3
Predictable tail latency	2	5	4	2	3
Hiring depth in Egypt	5	2	4	5	4
Hiring depth in KSA and UAE	4	2	4	3	4
Readability for auditors	5	4	3	3	3
Supply-chain discipline by default	3	4	4	3	2
Boring, well-understood deploys	4	5	5	4	4

If most of your weight sits in the top rows, choose Python and plan to extract one or two hot services later. If most of it sits in the throughput and latency rows, start elsewhere and bring Python in for data and tooling.

The hybrid that usually wins

For most regional fintechs: Python for the application layer, data platform and tooling; PostgreSQL as the system of record; a few services in Go or Rust where latency demands it. The mistake is rarely choosing Python; it is choosing Python without the discipline that makes it safe for money.

FAQ

Is Python fast enough for a payment gateway?

For the orchestration layer, yes, comfortably. A payment request spends almost all its time waiting on the PSP, the bank and the database; Python's job is to coordinate, validate and record, and an async or multi-process deployment handles more throughput than most regional products will see. It is not fast enough for a matching engine or a microsecond risk gate, and those should be separate services anyway.

Should we use Django or FastAPI for a fintech backend?

Django when the product has a large admin and back-office surface and the workload is mostly database-bound. FastAPI when the service is an API-first integration layer that fans out to many external calls. Many teams run both: Django for the back office and ledger, FastAPI at the edge. Neither choice will make or break the product; Decimal, idempotency and the ledger design will.

How do we handle money safely in Python?

Never use float. Represent amounts as Decimal or integer minor units, carry the currency with the amount, round once with a named mode at a known place, and make the ledger double-entry and immutable. Validate every amount at the boundary, store amounts in PostgreSQL NUMERIC columns, and write tests that assert fee plus net always equals gross.

Can Python pass a PCI DSS or central bank audit?

Yes. Audits assess controls, not languages. Keep card data out of your Python services by tokenising at the edge, manage secrets properly, pin and audit dependencies, produce an SBOM, keep immutable audit logs, minimise PII, and host where the regulator expects. A Python codebase that does those things is easier to examine than a faster codebase that does not.

Is it hard to hire Python engineers in Egypt, Saudi Arabia and the UAE?

Hiring Python engineers is comparatively easy, especially in Egypt. Hiring Python engineers who have worked with money, understand idempotency and can defend a ledger design is hard everywhere, including here. Hire for fundamentals, pair new engineers with the reconciliation and risk teams, and expect to grow fintech expertise internally rather than buy it.

Key takeaways

• Python's natural home in fintech is the money-adjacent layer: integrations, risk, data, reporting and back office; the core can be Python too, with discipline.
• Money is never a float. Use Decimal or integer minor units, round once with an explicit mode, and derive remainders rather than rounding twice.
• Every endpoint that moves money is idempotent, keyed by the caller, with the key forwarded to the provider.
• Balances are derived from an immutable double-entry ledger; the invariant is enforced in Python and again in PostgreSQL.
• The GIL rarely limits I/O-bound fintech workloads; use processes, asyncio where fan-out is high, queues for everything slow, and a pool in front of PostgreSQL.
• Supply-chain hygiene (lockfiles with hashes, continuous auditing, SBOMs, a private index) is where Python teams most often fail an examiner.
• Data residency and PII minimisation are architectural decisions in Saudi Arabia, the UAE and Egypt, not afterthoughts.
• Hire for fundamentals rather than framework trivia, and choose Python when the product is rules and integrations; isolate it where microsecond latency is the product.