Open Source, FINOS and the Cloud-Native CIB Stack

TL;DR. How FINOS, the Linux Foundation and a Rust-and-zero-dependency stack are reshaping the cloud-native CIB stack — talent, compliance, PSD3 and supply-chain provenance.

Key takeaways

01. Why CIBs are going open. Three pressures push CIBs toward open source, and none of them are ideological.
02. The Rust-and-zero-dependency stack. The cloud-native CIB stack in 2026 is no longer the LAMP-era picture of "open source = Linux + nginx + Postgres".
03. Open source underpins ISO, AI and quantum agendas. The three structural CIB agendas of 2026 — ISO 20022 cutover, agentic AI in operations, and post-quantum cryptography migration — all run on inspectable code.
04. Platformisation under PSD3 and FiDA. The European platformisation agenda — PSD3, the Payment Services Regulation, and the Financial Data Access framework (FiDA) — is a regulatory commitment to open finance.

In June 2026, the corporate-investment-banking (CIB) technology agenda finally stopped pretending. Morgan Stanley, JPMorgan and Citi sit on the FINOS governing board and are now treating open source as core infrastructure, not a side project — a shift Banking Dive captured in its recent reporting on the three banks doubling down on shared code through FINOS and the Linux Foundation (Banking Dive, 2026). The reason is uncomfortable for vendors: the CIB stack now needs to be inspectable end-to-end, and proprietary boxes do not survive a DORA Article 5 audit.

This article connects that shift to the engineering side. The Rust libraries I publish — noyalib, http-handle, hsh, KyberLib, html-generator, Shokunin SSG — are not the point on their own. They are concrete examples of what a cloud-native CIB stack now looks like when you take the FINOS thesis seriously: permissive licences, zero unsafe, signed artefacts, and supply-chain provenance baked in at compile time.

01. Why CIBs are going open #

Three pressures push CIBs toward open source, and none of them are ideological.

Talent. The strongest infrastructure engineers in 2026 build in public. The 2025 FINOS State of Open Source in Financial Services report puts the contributor base on the high side of growth, with bank-affiliated maintainers now visible across CNCF runtime projects and FINOS workstreams (Linux Foundation, 2025). When a Tier-1 CTO needs a senior Rust or Kotlin engineer who can ship a clearing-system rewrite, that engineer expects to commit upstream. Proprietary-only shops lose the hiring conversation early.

Compliance. DORA Article 5 puts non-delegable ICT-risk accountability on the board. Basel III ties operational-risk capital to outages. Both regimes assume the institution can audit every component in the production path — and that is structurally easier with permissive open-source code under MIT, Apache 2.0 or BSD-3-Clause than with a black-box ISV release where the SBOM is "trust us". CycloneDX and SPDX bills of materials, SLSA provenance attestations and sigstore signatures are now the minimum bar a regulator expects to see attached to a release pipeline.

Delivery speed. A CIB platform team that ships a payment-engine change in days rather than quarters is not winning on heroics. It is winning on shared substrate — Kubernetes, OpenTelemetry, ISO 20022 schema libraries, FINOS Common Domain Model — that nobody pays to re-implement. The economics no longer favour bespoke rails.

Three pressures, one conclusion. Going open is a delivery decision, not a procurement one.

02. The Rust-and-zero-dependency stack #

The cloud-native CIB stack in 2026 is no longer the LAMP-era picture of "open source = Linux + nginx + Postgres". It is a layered set of permissively licensed, memory-safe components — each with its own SBOM, its own provenance, and its own minimal threat surface. The Rust libraries I maintain map cleanly onto that layering.

Edge ingress. http-handle is a zero-dependency, RFC 7230 / 9112-compliant HTTP/1.1 server written in safe Rust — built for the moment a CIB platform team realises the ingress layer should not pull in 200 transitive crates. The case for it is laid out in http-handle: Zero-Dependency Edge Ingress for Banking in Rust.
Configuration plane. noyalib parses YAML 1.2 with 406/406 spec compliance, JSON-Schema validation and a lossless concrete syntax tree — so Kubernetes manifests, MCP server registries and CI workflows stop being a silent attack surface. See Why YAML Needs a Safer Rust Stack for AI, MCP, and Financial Infrastructure in 2026.
Cryptographic primitives. hsh provides Argon2id, bcrypt and scrypt password hashing with a constant-time verification API. KyberLib implements ML-KEM-512/768/1024 under FIPS 203 for the post-quantum migration explored in KyberLib and the Post-Quantum Banking Migration in 2026.
Content and edge delivery. html-generator compiles accessible Markdown into structured HTML; Shokunin SSG builds the publication you are reading; CloudCDN sits in front of it as an open-source, AI-native edge.

None of these are "frameworks" in the legacy banking sense. They are small, permissively licensed, signed components with explicit threat models. That is the operational shape the FINOS thesis encourages — and the shape a CIB platform team can defend in front of a regulator without a slide deck.

A small honest caveat: the goal is not "rewrite the bank in Rust". It is to give CIB platform teams the option of a memory-safe, low-dependency stack at the load-bearing layers — ingress, parsing, crypto, build, supply chain — without forcing a religious decision elsewhere.

03. Open source underpins ISO, AI and quantum agendas #

The three structural CIB agendas of 2026 — ISO 20022 cutover, agentic AI in operations, and post-quantum cryptography migration — all run on inspectable code. None of them work as proprietary stacks.

ISO 20022. The pacs.008 / pacs.009 / camt schema family is now the wholesale-payments default. FINOS hosts the Common Domain Model alongside open-source Java and Kotlin libraries that parse, validate and route those messages. The work in pacs.008 Automation and ISO 20022 Interbank Payments shows how a clearing-grade pipeline composes from those open components — schema validation, structured remittance, end-to-end traceability — without rebuilding the parser at every bank.

Agentic AI. The Model Context Protocol (MCP) is the lingua franca for letting AI agents call internal banking tools — and MCP servers run on YAML registries, OAuth-bounded service accounts and audit-log pipelines. The control plane is open source because it has to be: any agent that touches a production ledger needs an inspectable bounded workflow. The argument for treating that as an engineering problem rather than a vendor selection runs through Why YAML Needs a Safer Rust Stack and the dotfiles workstation work at AI-Aware Dotfiles in 2026.

Post-quantum cryptography. FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) are now the migration targets. The hybrid X25519MLKEM768 key-exchange is the practical default in TLS 1.3. None of this works without open implementations that auditors and bank cryptography teams can read line by line — KyberLib being one example, and the broader migration framing being the subject of KyberLib and the Post-Quantum Banking Migration in 2026.

Three agendas. One shared dependency: open code, signed by sigstore, attested by SLSA, listed in a CycloneDX or SPDX SBOM, governed by OSSF scorecards. That is the cloud-native CIB stack in 2026.

04. Platformisation under PSD3 and FiDA #

The European platformisation agenda — PSD3, the Payment Services Regulation, and the Financial Data Access framework (FiDA) — is a regulatory commitment to open finance. It assumes banks can expose, govern and audit data flows at scale. Open standards are the precondition, not the side-effect.

Consultancy.uk's 2026 outlook on orchestrating open banking for platform growth makes the same observation from the business side: the institutions winning under PSD3 are the ones that treat the API estate as a product, not as a compliance afterthought (Consultancy.uk, 2026). That posture is impossible on a closed stack. Productising APIs needs versioned OpenAPI specifications, automated contract tests, observability across every consumer, and a governance layer that an auditor can walk through. Every one of those primitives is open source in 2026, and most of them sit in CNCF or FINOS projects.

The same logic extends to FiDA's wider data-access perimeter — pensions, mortgages, investment products. A bank that controls its parsing, ingress, configuration and crypto with inspectable code can extend the perimeter without re-architecting. A bank that has outsourced those layers to closed vendors will be paying integration consultants for the next three years. The FINOS thesis is, at heart, a platformisation thesis: own the standards, share the substrate, compete on the surface.

Conclusion #

The CIB stack in 2026 is open by default. Not because of ideology, but because the three pressures — talent, compliance, delivery speed — pull in the same direction, and the regulators (DORA, Basel III, PSD3, FiDA) have ratified it. The Banking Dive reporting on Morgan Stanley, JPMorgan and Citi is the public version of a private conversation senior platform teams have been having for two years.

For boards, the implication is straightforward. The question is no longer "should we use open source". It is: do we have the SBOMs, the SLSA provenance, the sigstore signatures, the OSSF scorecards, and the FINOS-aligned contribution policy to use it safely. If the answer is no, the answer to the regulator will also be no.

For engineering leaders, the implication is sharper. Pick the load-bearing layers — ingress, parsing, crypto, build, supply chain — and standardise on permissively licensed, memory-safe components with explicit threat models. The Rust-and-zero-dependency examples in this article are one valid set. The point is the shape, not the brand. Build the substrate so the surface can move fast.

Open source is no longer the modernisation question. It is the modernisation answer.

Last reviewed 2026-06-29.

Republish this article

Open Source, FINOS and the Cloud-Native CIB Stack

How FINOS, the Linux Foundation and a Rust-and-zero-dependency stack are reshaping the cloud-native CIB stack — talent, compliance, PSD3 and supply-chain provenance.

This article is licensed under Creative Commons Attribution 4.0 International. Republication requires attribution to the canonical URL.

Open Source, FINOS and the Cloud-Native CIB Stack

How FINOS, the Linux Foundation and a Rust-and-zero-dependency stack are reshaping the cloud-native CIB stack — talent, compliance, PSD3 and supply-chain provenance.

Originally published at https://sebastienrousseau.com/2026-06-28-open-source-finos-cloud-native-cib-stack-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER

Open Source, FINOS and the Cloud-Native CIB Stack

01. Why CIBs are going open #

02. The Rust-and-zero-dependency stack #

03. Open source underpins ISO, AI and quantum agendas #

04. Platformisation under PSD3 and FiDA #

Conclusion #

Format for Medium

Format for Mastodon

Copy formatted for LinkedIn

BibTeX

RIS

Vancouver

Chicago

APA

Republish this article