NextSabi
NextSabi is the conversion of SABI into a generic, multi-tenant posting platform, deployable as SaaS or inside the client’s own infrastructure. The thesis, verified by reading the legacy source: the transactional core holds no business logic, it interprets a catalogue of rules. The work was to rescue that abstraction, not to invent one.
Architecture on one page
Five layers, each with one job. The one that decides what gets posted is a pure function: give it the pack, the rules, the formulas, the calendar and a snapshot of balances, and it returns entries and deltas — or a typed error.
Decisions that explain everything else
The core does no I/O
It receives everything it needs and returns entries or a typed error. That is what makes it testable by mutation and portable between database engines.
Rules are versioned, approvable data
Not code. A pack is the complete catalogue of a market, and several packs coexist in the same tenant.
One schema per tenant
Back up, restore or hand a regulator one client’s data without touching anyone else’s.
Money as text on the wire, Decimal in memory
Never floating point. A JSON numeric 5.5 is rejected.
Zero money arithmetic in SQL
And all SQL in a single module. That is what made SQL Server possible in two sessions.
The settlement ladder is computed on read
Not stored rebuilt as in the legacy system, so it cannot drift out of sync.
Mandatory idempotency key
Which fixes the legacy bug where a retry duplicated the position.
Typed errors with a legacy code alongside
So an existing consumer keeps reading the return code it already knows.
Packs: a market’s whole catalogue
A pack is the complete catalogue of a posting application: its balance-key dimensions, its settlement horizons, its measures, its amount formulas and its rules. Several packs coexist in the same tenant, each with its own book.
The packs cover the same markets SABI covers today: money, equities, mutual funds, FX, derivatives and treasury, each one translated attribute by attribute from the real catalogue.
Money Market
sabi-md
The largest pack in the catalogue. The desk trades against its own inventory: it opens a position, sells to the client and keeps the maturity calendar and coupon interest, with the module’s 24 formulas.
Equity Markets
sabi-mc
Order and assignment with commission and VAT, and the weighted average cost computed at the right horizon.
Mutual Funds
sabi-si
Fund catalogue, trading day, capture, blotter and cancellation. Multi-series, non-overlapping series ranges, blocks and holding limits.
FX Market
sabi-cambios
The catalogue’s currency trading, scoped to the DLL instrument: spot purchase and sale (CCD/VCD), forward (VCCA, VCCD, VVCA, VVCD) and their guarantees. A pack of its own, meant for an exchange house or a fintech that only exchanges currency.
Derivatives Market
sabi-der
Two worlds in one pack: OTC (forwards and swaps, with order and assignment citing the folio, like equities) and exchange-listed with a clearing house, with margin contributions and daily variation as in MexDer. 83 of its 85 types operate.
Treasury
sabi-tesoreria
Deposits and withdrawals with the real rules from the legacy catalogue, translated attribute by attribute. The pack that first proved literal translation works.
Full catalogue
sabi-catalogo
The whole deciphered catalogue in one pack, to explore what is there before deciding which market gets converted next.
Every pack shares the same geometry: ten balance-key dimensions, eight cumulative settlement horizons, measures identified by name and horizon, and the amount formulas of the legacy library. A brand-new market is a new pack, not a new engine.
The HTTP service
Everything a capture application, a portal or a third party needs, with roles, sessions and an audit trail on every write.
- Posting with a mandatory idempotency key
- Balances with the settlement ladder by horizon
- Trading day: traffic light, schedules, closings
- Fund catalogue with series, ranges, blocks and holding limits
- Blotter and cancellation: posting a linked entry with a typed reason, one single reversal
- Shadow mode: captures, reconciliation and signed intentional divergences
- Sessions with scrypt and an HttpOnly cookie; administrator, operator and read-only roles
- Temporary password with a forced change, session revocation
- Per-tenant configuration with an immutable history
- Uniform errors with a typed code and the legacy return code
Integration: today’s SOAP, tomorrow’s REST
The two SOAP services SABI exposes today are answered exactly as they are — WSDL, Fault, both namespace generations, the flat XML inside the payload and the “SISTEMA CERRADO” prose included. The tests use the real consumer’s parser, copied verbatim, as the oracle. Alongside them lives the REST equivalent, with typed codes and idempotency.
The practical consequence: the systems already integrated with SABI do not have to change on the day the platform takes over.
Deployment and portability
- PostgreSQL and SQL Server 2022 posting the same corpus of real rules and matching to the cent
- Twenty-two schema guarantees: append-only book, unique cancellation, rule versions without overlap
- Docker image in two stages; the Rust core ships compiled as a Python wheel
- Reproducible demo: one command regenerates schema, packs, administrator, parameters and smoke test from an empty database
- Deployable as SaaS or inside the client’s own infrastructure
- Roadmap: Oracle, concurrency certification, OIDC for federated identity
What we do not claim
The success criterion is not “programs converted”, it is zero divergences against the legacy system, to the cent. That is why we always separate what is proven from what is assumed and what is missing — and we publish the third list too.
Parity to the cent against production
Everything is translated literally and verified against oracles traced by hand, but the definitive proof is shadow mode running beside the legacy system.
That the calendar, VAT and credit-card accounts are the real ones
They are marked as assumptions or as inputs until the data arrives.
Latency figures for the arbitrage prototype
It runs on delayed data and simulated execution. No number is promised until it is measured against a real feed.
See it running
The demo is a twenty-minute script: open the trading day, capture a purchase and watch the entries the real catalogue generates, cancel it from the blotter, run a deposit and a withdrawal in treasury, and answer the existing SOAP service from the consumer that already uses it.