Bankster API / 6 articles

Software & models

The decisions between a calculation that works and a system people can rely on.

Financial software has to preserve meaning as a calculation moves between languages, databases and business systems. A result can depend on a rounding convention, an input version or whether a retried event changes a ledger twice.

Explore the implementation choices that carry those assumptions, from a notebook calculation to a production service.

Exactly-once delivery and exactly-once financial effects

Delivering an event once and applying its financial effect once are different guarantees. Explore retries, deduplication and ledger boundaries.

Read article

Why financial firms use several programming languages

Why trading, pricing and operations use different languages—and how memory, latency and numerical workloads shape the choice.

Read article

From notebook to model service: preserving a financial calculation

Moving a calculation into production requires more than packaging code. Preserve inputs, versions, units and execution assumptions.

Read article

Decimal arithmetic does not choose a rounding policy

Decimal arithmetic cannot decide when to round. A worked example shows why line-item and aggregate rounding produce different balances.

Read article

Transaction databases, tick stores and search indexes

Ledgers, tick stores and search indexes preserve different facts. Learn why one database rarely serves every financial workload.

Read article

Where CRM and ERP sit in a financial institution

Client records and business accounts do not replace trading or settlement systems. Explore where CRM and ERP connect to financial workflows.

Read article