Banking infrastructure security in 2026 is no longer decided at the perimeter or the application. It is decided at the substrate. Financial institutions deploying Adaptive Financial Infrastructure inherit the security properties of the platform they build on.
Tenant isolation, event-level auditability, continuously evidenced controls, and a credible third-party assurance posture are inherited, not assembled. This post explains what SOC 2 Type II actually demonstrates, what operating against ISO 27001:2022 signals about operating mode, how vendor isolation works in practice, and what procurement and risk teams should evaluate before signing.
For most of the last decade, banking infrastructure security was framed as a stack: perimeter, application, data, identity. The buyer’s job was to assemble the right combination and demonstrate it to regulators.
That framing has not aged well. The defining banking infrastructure breach pattern of 2025 and 2026 has been substrate failure. Compromised OAuth tokens propagate across SaaS supply chains, third-party integrations carry inherited trust into customer environments, and machine identities operate below the line where most security programs have visibility. The Cloud Security Alliance’s State of SaaS Security Report found that “46% of organizations struggle to monitor non-human identities” and “56% report concerns about overprivileged API access.”1 These are the structural conditions under which a single compromised integration can cascade across hundreds of downstream customers. Financial institutions inherit the security posture of every platform their infrastructure runs on, whether the contract says so or not.
Substrate-level security means the security properties of a banking platform are characteristics of the infrastructure itself, not bolted-on controls layered above it. Tenant isolation is structural. Auditability is event-native. Control evidence is continuous. Third-party assurance is operational. The financial institution adopting the platform inherits these properties as substrate, not as configuration.
The distinction matters because the architectural altitude at which security is implemented determines what gets inherited. Application-level security protects a workload. Perimeter-level security protects a boundary. Substrate-level security protects every workload, every boundary, every data flow, and every machine identity by construction. The Bank for International Settlements framed the underlying architectural shift in its 2025 Annual Economic Report: “Tokenisation integrates messaging, reconciliation and settlement into a single seamless operation.”2 The same architectural altitude that makes unified-ledger finance operationally coherent (one substrate, one live context, one audit surface) is what makes security inheritable rather than assembled.
The AFI Platform is built to this standard. The event-native architecture (Apache Kafka and Apache Iceberg as substrate) means every state change is an auditable event by default. The tenant-isolation model means each financial institution operates in its own cloud account, with no shared data plane between customers. The continuously evidenced control posture means assurance is a running state, not a point-in-time artifact.
SOC 2 Type II attests that an organization’s controls relevant to security, availability, processing integrity, confidentiality, and privacy operated effectively over a defined examination period, typically six to twelve months. It is the operational floor for any vendor handling financial-institution data, not the differentiator.
The substantive signal is the gap between policy and practice over time. Type I tests design at a point in time. Type II tests whether controls held under load, under change, and under incident response across the examination window. The AICPA’s 2025 white paper, A Guide to Vendor Management and Third-Party Risk Reviews, extended this orientation explicitly toward ongoing monitoring and active vendor oversight.3 The framework reads vendor risk as an active oversight discipline, not a procurement checkbox.
XYB maintains SOC 2 Type II attestation across the AFI Platform and the controls that govern its development, deployment, and operation. These are the same control families a financial institution is held to under its own regulatory baseline. The current attestation period and report are available through the XYB Trust Center. The right way to read this attestation is as evidence of operational discipline, not as the end of vendor diligence.
ISO 27001 is a management-system standard, not a control checklist. The substantive signal is whether the vendor operates a functioning Information Security Management System with continuous evidence of conformance. Operating against the 2022 revision of the standard signals two things: the ISMS is current with the most recent control framework rather than running on legacy mappings, and the operating mode behind it is observable rather than periodic.
XYB’s ISMS operates against the ISO/IEC 27001:2022 standard, with certification underway, the full Statement of Applicability mapped to the AFI Platform’s operational scope, and control state continuously evidenced through XYB’s Trust Center, powered by Vanta.4 The 2022 revision reorganized Annex A into four themes (organizational, people, physical, and technological) and modernized the control set to reflect how security work is actually done in event-native, cloud-native infrastructure environments. Operating against this revision, with control state tracked live rather than reconstructed at audit time, is the operational difference between a vendor that can demonstrate posture on demand and one that can demonstrate it once a year.
The control inventory under continuous evidence covers privileged access rights, secure authentication, cryptographic controls, logging and monitoring, secure development lifecycle, data leakage prevention, and separation of environments. This is the substrate on which financial institutions performing their own third-party risk assessments run their evaluation. The platform has been measured against this baseline by financial-institution customers under their own risk frameworks and has passed. A certificate, once issued, is a credential. The operating mode and the diligence record together are the assurance.
Each financial institution running on the AFI Platform operates in its own dedicated cloud account, most commonly AWS or Google Cloud, with other hyperscalers available where the institution requires it. There is no shared data plane, no multi-tenant database with logical partitioning, and no cross-customer service dependencies in the data path. This is single-tenant architecture: isolation is structural, not configured. The architecture treats each financial institution’s deployment as a sovereign environment. Compute, storage, ledger state, event streams, observability data, and cryptographic key material live within the institution’s own AWS or Google Cloud account. The institution retains the access control, audit visibility, and operational governance that account ownership confers. There is no failure mode in which a compromise of one tenant’s environment exposes another’s, because the environments do not share infrastructure to compromise.
For the financial institution’s risk team, this scopes the vendor’s blast radius to the platform code and the operational team that deploys it. For regulators evaluating concentration and operational resilience, it removes the systemic dependency that single-tenant assurance frameworks are designed to surface. For the AI agents reasoning across the institution’s environment, unifying context in real time, that context is sovereign to the institution, not shared substrate.
The event-native architecture compounds the isolation. Every transaction, every state change, and every administrative action emits an event into the institution’s own Apache Kafka topics, materialized into its own Apache Iceberg tables. The audit trail is not a separate logging pipeline that could be misconfigured or bypassed. It is the data plane.
Four questions distinguish the platforms that will hold under regulatory load from those that will not.
Is tenant isolation structural or logical? Does each financial institution operate in its own AWS, Google Cloud, or equivalent cloud account, or in a partitioned slice of shared infrastructure?
Is auditability event-native or appended? Does the platform emit an immutable audit trail by construction, or run a separate logging pipeline that can drift?
Is control evidence continuous or periodic? Is the ISMS state observable at any moment, or only at certification time?
And what is the record of customer due diligence? Which financial institutions have evaluated the platform under their own third-party risk framework and signed?
These are substrate questions, not feature questions. The institution that asks them gets a vendor evaluation that survives the audit it will face two years after signing.
The financial institution that evaluates banking infrastructure on substrate-level questions buys a platform whose security properties hold across every workload it runs, every event it emits, every audit it survives, and every regulatory wave it absorbs. That is what makes banking orchestration on the AFI Platform durable: not the attestations themselves, but the substrate the attestations describe.
For the procurement, risk, and compliance evaluation: the XYB Trust Center publishes the current attestation set and supporting documentation at trust.xyb.co.
For the architectural conversation, read the AFI Platform overview, or the category-level framing in What is Adaptive Financial Infrastructure?
The Trust Center publishes the current attestation set and supporting documentation for procurement, risk, and compliance review.