From Profile to Interchange
In my first article in the AI governance series, I compared the AI governance evolution to the FIX moment. It ended ended with a specific proposal: build a Financial Services Profile for Google’s A2A protocol: domain-specific extensions declaring agent identity, compliance metadata, entitlement boundaries, and liability allocation. By my understanding at the time, the logic was clean. A2A provides agent-to-agent coordination. Financial services needs governance at the organizational boundary. Extend the protocol with a domain-specific profile, the way RIXML extended XML for research exchange. Ship it through FINOS.
Then I sat down to pen a concrete proposal to paper and the ensuing research made me realize that my original thought process was too narrow. Over the last four weeks of deep research that included reading hundreds of sources, five stress-tests, four steel-manned counterarguments that I built for myself, and a hostile reviewer pass designed to find what I’d missed, I came to a much different conclusion.
The first thing that broke the A2A extension thesis was where cross-enterprise agent interactions are actually happening in financial services. Not A2A. MCP.
- Bloomberg launched AI Ready Data on MCP in early 2026: governance middleware wrapping every agent interaction with identity verification, access control, audit logging, rate limiting, and metering. All proprietary, all Bloomberg-native.1
- FactSet did the same with AI Data Mesh: MCP as a primary distribution channel with governance layered on top, no shared vocabulary with Bloomberg’s implementation.2
- LSEG shipped Trusted AI Ready Content with equivalent governance controls, a third independent implementation of the same categories.3
Three data vendors with their own governance stacks. Identical categories (identity, access control, audit, metering) built independently, on the same protocol, with no reported interoperability between them. The parallel to pre-HL7v2 healthcare, where every hospital exchanged lab results through custom point-to-point interfaces, is precise.
Then the pattern accelerated:
- Kong and Apigee shipped MCP-specific gateway infrastructure (identity enforcement, ACLs, audit logging, rate limiting) making governance middleware available as API gateway configuration rather than custom engineering.4
- On April 14, 2026, while I was drafting this article, Cloudflare published a full reference architecture for enterprise MCP governance. Not a whitepaper but a full production system, internally validated across their product, sales, marketing, and finance teams before publication: Cloudflare Access as OAuth provider, MCP Server Portals aggregating upstream servers behind a single enforcement point, DLP (Data Loss Prevention) scanning via Gateway body inspection, shadow MCP detection monitoring corporate traffic for unauthorized agent protocol usage, and full audit logging with SIEM export via Logpush.5
- Days later at Cloud Next, Google shipped Agent Gateway as part of Gemini Enterprise Agent Platform, the first gateway covering both A2A and MCP in a single enforcement surface, with Symantec DLP integration and Model Armor for prompt injection protection.6
- Oracle published a runtime governance framework reframing the unit of control from the model response to the governed action trajectory: four-layer control model, structured decision records, pre-execution policy evaluation. All intra-enterprise, no schemas published.7
- AWS shipped a Cedar-based policy engine on AgentCore Gateway, generally available across 13 regions since March 2026: deterministic rules intercepting every agent-to-tool call, fine-grained controls on user identity and tool input parameters, each session isolated in its own Firecracker microVM.8

Eight firms across five categories (three data vendors, two API gateway providers, a hyperscale infrastructure company, the protocol’s creator, and the largest cloud platform) have each independently built governance middleware for agent interactions. Every implementation is capable. Every implementation is platform-native. And not a single one has published an interchange format for what happens when a governed agent on one platform calls a governed agent on another.
That was the finding that generalized the thesis. The governance schema is protocol-invariant: what you need to communicate across firm boundaries (organizational identity, audit attestation, data entitlements, liability allocation) is identical whether the interaction travels over A2A, MCP, or both in the same transaction chain. The schema is the durable layer. The transport binding is replaceable. An A2A-only profile solves half the problem for the protocol financial services isn’t primarily using yet.
That is why in this article, I propose AFIX, the Agentic Financial Interoperability eXchange. Not a protocol extension but a protocol-agnostic governance interchange format in JSON, with transport bindings to both A2A and MCP; designed so that Bloomberg’s governance middleware, Cloudflare’s gateway enforcement, and AWS’s Cedar policies can all produce and consume the same governance metadata. I’ve published the schemas in the linked Github repo, the research methodology is open as well, and every claim in what follows has been stress-tested against the strongest counterarguments I could construct. This article explains the design, the evidence, and is honest about where further enhancements are needed and what is not in scope.
The Unsolved Gap in AI Governance
The previous article in this series broke intra-enterprise agent governance into five concentric layers.
At Layer 1, open-source enforcement frameworks are emerging. I built The Bulwark to address the practitioner-level gap directly: hooks as governance primitives, deterministic rules injected at session start, pre- and post-tool execution gates that do not rely on the model remembering to comply. OWASP’s Agentic Top 10 provides the threat taxonomy.9 Claude Code’s hook system provides the underlying mechanism.10 These are working systems, built bottom-up because the layers above do not reach the individual practitioner’s daily workflows.
At Layer 2, platforms provide structural controls (sandbox isolation, permission models, credential management) but the gap between “can the agent do it?” and “should the agent do it?” remains open in most harnesses.
Layer 3 is where the serious money lives, and where the landscape has shifted materially since that article was published.
- JPMorgan Chase allocates $18 billion annually to technology and has deployed over 450 AI use cases, including agentic systems, under firmwide AI governance led by its Chief Data & Analytics Officer on the Operating Committee.11
- Morgan Stanley created a dedicated Head of Firmwide AI role and a Firmwide AI Steering Group, building an eval-driven governance pipeline that gates AI deployment through quantitative performance benchmarks before production release.12
- BlackRock embeds AI risk governance within its enterprise risk framework, runs mandated company-wide AI training programs, and operates a dedicated AI Labs research division focused on applying AI across investment management and risk.13
- Bloomberg’s proprietary MCP middleware wraps every agent interaction in identity verification, access control, audit logging, rate limiting, and metering. Governance so comprehensive that a buy-side firm pulling Bloomberg data through an agent operates entirely within Bloomberg’s enforcement surface.1
These are not paper commitments. Each firm has built production governance infrastructure, staffed dedicated teams, and embedded AI risk into existing enterprise risk frameworks. The spending is real, the executive attention is real, and the internal discipline advances quarter over quarter.
Cross-firm collaboration exists at this layer too, on governance frameworks. FINOS Common Controls for AI (CC4AI), with BMO, Citi, Morgan Stanley, RBC, Goldman Sachs, and major technology vendors contributing, published the AI Governance Framework (AIGF) v2.0 in early 2026. Training workshops ran through April. The framework covers risk taxonomies, control mapping, and organizational governance maturity: 23 identified risks, 23 mitigations, the kind of shared vocabulary that helps firms align on what good internal governance looks like.14
But framework coordination and interchange coordination are different things. AIGF covers risk taxonomies, control mapping, and organizational governance maturity: the shared vocabulary for what good internal governance looks like. Its mitigations address agent identity, audit trails, access control preservation, and liability allocation. Every category that matters for governance. But every mitigation stops at the enterprise boundary. AIGF defines what a firm should enforce internally. It does not define a wire-format specification for what governance metadata crosses the boundary between two firms when their agents interact. The firms contributing to CC4AI and the firms building the most sophisticated internal governance infrastructure are investing heavily in frameworks and internal systems, but my research did not indicate similar investments in standardizing interchange. So while the internal governance investments are real, there is little to no information available on the investments made to govern coordination.
Furthermore, the regulatory convergence makes the timing urgent. The EU AI Act’s high-risk system requirements reach enforcement in August 2026, creating the obligation: regulated firms deploying AI agents in high-risk categories (creditworthiness assessment, insurance pricing, employment screening) must demonstrate conformity with Articles 9 through 15, covering risk management, data governance, transparency, human oversight, and accuracy.15 ISO 42001 adoption is accelerating as the certification gold standard for AI management systems, creating the certification: a third-party auditable standard that proves an organization manages AI risk systematically.16 But neither addresses what happens at the boundary.
When your ISO 42001-certified agent calls my ISO 42001-certified agent, both firms can prove they manage AI risk internally. Neither can prove the interaction was governed. The obligation & the certification both exist. The interchange format does not.
Cross-border interactions compound the problem. EU GDPR data localization requirements can conflict with US SEC record-keeping obligations. The EU AI Act’s transparency mandates can collide with US trade secret protections. When a US-regulated agent sends governance metadata to an EU-regulated agent, that metadata itself (actor identity, escalation contacts, organizational identifiers) may constitute personal data under GDPR. The current AFIX schema declares jurisdictions but does not resolve conflicts between them. This is a known design problem for v2, not an oversight. The schema needs a conflict detection mechanism before it can credibly support cross-border agent interactions at scale.17
AFIX proposes what the industry needs at the cross-enterprise interchange layer that the previous article identified but deliberately left for this one. The four layers in between are well-funded and advancing. The interchange layer has no peer, no standard, and no proposal other than this one.
The alternative to an industry-native governance standardization is hyperscaler-led de facto standardization. Google controls the A2A specification, chairs the Agentic AI Foundation alongside Anthropic, and has the platform reach to ship governance as a product feature.6 AWS’s Cedar policy engine, Cloudflare’s Access JWT assertions, and Google’s Agent Gateway policies are already three incompatible governance vocabularies: three ways to express identity, three audit event formats, three entitlement models, none of which interoperate.5,6,8
The biggest question all of us should be asking is:
Should Financial Services & Fintech define an industry-native agent interchange governance standard or inherit whatever Silicon Valley hyperscalers come up with?
Taking Inspiration From Precedent
When an industry hits a coordination problem at the boundary between firms, it standardizes the interchange, not the implementation. The pattern repeats across every regulated industry that has faced this.

- FIX embedded governance metadata in trade messages starting in 1993: ComplianceID, SolicitedFlag, and the Parties block travel alongside execution data, making the message itself the audit trail. Two firms with completely different order management systems can still govern a cross-boundary trade because the governance vocabulary is in the wire format, not the implementation behind it.18
- HL7 FHIR introduced capability-based architecture with multi-transport binding and a formal extension mechanism: domain-specific fields without modifying the core specification, adopted by healthcare systems that had spent decades suffering under the N-squared integration problem that custom point-to-point interfaces create.19
- RIXML pioneered tiered adoption with a minimum viable envelope: implement what you need, when you need it, against an existing base protocol. The design insight that made MiFID II compliance tractable for research distribution when the regulatory mandate arrived seventeen years after the standard was published.20
The first article in this series covered this historical pattern in depth: the conditions under which standards emerge, the trajectories that succeed, and the ones that fail. AFIX follows the same template: a governance interchange format that works with both A2A and MCP, the way FIX works across multiple transport layers. The schema is the durable contribution. The transport binding is the replaceable detail.
But that article ended with a specific constraint:
The governance standard that wins will not be the most comprehensive one. It will be the one simple enough to adopt in weeks.
FIX succeeded with ASCII key-value pairs over TCP sockets. FHIR succeeded with REST and JSON. HL7 v3 failed with a Reference Information Model that required specialist knowledge to implement. That lesson shaped every design decision in what follows.
AFIX is simply a set of JSON properties that attach to existing protocol messages and travel with every agent interaction. No new transport. No custom parser. No domain-specific tooling required. A team that already runs A2A or MCP agents can read the schema, map it to their internal governance systems, and start emitting governance metadata in the format their counterparties can consume. The complexity is in the governance policy, where it belongs. The interchange format is deliberately simple. The next section covers this in detail.
AFIX: A Deep Dive Into The Schema
AFIX is a protocol-agnostic Financial Services Agent Governance Schema. It defines what governance metadata crosses the boundary between two independently governed organizations. Only that and nothing more.
In this proposal, internal governance systems such as Palantir AIP, ServiceNow GRC (Governance, Risk, and Compliance), AWS AgentCore, Google Agent Gateway, Databricks Unity Catalog, and other internal tooling would feed the schema. SIEMs (Security Information and Event Management platforms) consume it. AFIX defines only the interchange format. How a firm populates it internally would be that firm’s business.
One deliberate design boundary: AFIX specifies only the organizational governance interchange format (identity, entitlements, audit, liability). Model behavioral governance (runtime output quality, hallucination detection, accuracy attestation) is a complementary layer that AFIX does not address.
A firm can be ISO 42001-certified and still deploy a model that hallucinates a trade recommendation. AFIX’s Compliance Event will log that the action happened. Its Liability Metadata will allocate responsibility. But nothing in the schema prevents or detects the output failure itself. This is a scope decision, not an oversight. Practitioners familiar with SR 11-7 (now SR 26-2) model risk management will recognize that runtime behavioral attestation requires a different class of control than organizational governance interchange.

AFIX is made up of five components, each independently versioned following UCP’s (Universal Commerce Protocol) Capability/Extension/Profile pattern. The full JSON schemas are published at github.com/QBall-Inc/afix/schemas; what follows is the design rationale for each.
A note on namespace URIs. The published schemas use
finos.org/afix/v1/as their$idnamespace (e.g.,https://finos.org/afix/v1/agent-card). These URIs are illustrative. They represent the proposed target if FINOS adopts AFIX as a Community Specification. No such namespace exists today. FINOS has not adopted AFIX. The schemas, the research, and the proposal are published independently at github.com/QBall-Inc/afix. If you see afinos.orgURI in a schema file, read it as intent, not fact.
FS Agent Cards: Declare organizational identity and governance posture.
{ "organization": { "legal_name": "Meridian Capital LLC", "lei": "5493001KJTIIGC8Y1R12" }, "regulatory_jurisdiction": ["SEC", "FINRA"], "compliance_certifications": [{ "framework": "ISO_42001", "status": "CERTIFIED", "last_audit_date": "2026-01-15" }], "authorized_actions": { "categories": ["DATA_QUERY", "TRADE_RECONCILIATION"], "authority_thresholds": { "max_notional_usd": 5000000, "requires_human_escalation_above_usd": 1000000 } }, "escalation_chain": [{ "level": 1, "role": "AI Operations Lead", "sla_minutes": 15 }]}
AIGF’s MI-18 (Agent Authority Least Privilege) requires that agent identity be included in API invocations and that authority be scoped to the minimum necessary. The requirement is sound, and entirely intra-enterprise. Agent Cards carry that identity and authority declaration across firm boundaries, making MI-18’s internal discipline machine-readable to counterparties.
The identity anchor is LEI, the ISO 17442 Legal Entity Identifier, centrally issued by GLEIF (Global Legal Entity Identifier Foundation), requiring no new registry. Agent Cards carry ISO 42001 certification status via governance_certification_level tiers, from TIER_3_FULL (ISO 42001 certified with domain-specific audit) down to UNCERTIFIED. Supply chain attestation fields (ai_bom_reference, model_provenance) accommodate firms that publish AI-BOMs, optional today, increasingly expected as EU AI Act Article 13 transparency requirements take hold. Authorized action boundaries, authority thresholds, and an escalation chain for governance failures complete the card. Disclosure is tiered: a public layer (LEI, jurisdiction, protocol support) is discoverable via .well-known or tool invocation. A permissioned layer (authority thresholds, escalation chain, certification details) is exchanged only after bilateral governance negotiation, because a field like max_notional_usd is commercially sensitive and no firm will publish it to the open internet.21
Compliance Events: Provide the universal audit primitive.
{ "actor": { "agent_id": "research-agent-7", "organization_lei": "5493001KJTIIGC8Y1R12" }, "target": { "agent_id": "data-server-3", "organization_lei": "HWUPKR0MPOU8FGXBT394" }, "action": { "action_type": "DATA_ACCESSED", "risk_classification": "LEVEL_3_STANDARD" }, "timestamp": "2026-04-28T14:32:07.891Z", "authorization": { "status": "AUTHORIZED", "basis": [{ "policy_uri": "urn:afix:policy:data-query-v2" }] }, "outcome": { "status": "SUCCESS" }}
AIGF’s MI-21 (Agent Decision Audit) calls for tracking cross-agent dependencies and maintaining audit trails of agent decisions. Compliance Events provide the interchange format for that audit trail: a universal primitive that lets two firms’ audit systems speak the same language without sharing internal logging infrastructure.

A six-field interoperability core converged from three established audit standards: FIX ExecutionReport, FHIR AuditEvent R5, and RIXML’s Interactions Standard. Six fields: actor, target, action, timestamp, authorization, outcome. A compliance extension tier adds nine fields for regulatory minimums: model_id and dataset_version for EU AI Act Article 12 traceability, microsecond timestamps for MiFID II RTS 25 precision, and log_integrity_hash for SEC 17a-4 tamper-evidence. Regulations change faster than standards bodies. Domain extensions absorb regulatory change without modifying the interoperability core, the same pattern FIX uses with user-defined tags above 5000.22
Entitlement Interchange: defines what data and services each party can access across firm boundaries.
{ "grantor": { "organization_lei": "HWUPKR0MPOU8FGXBT394" }, "grantee": { "organization_lei": "5493001KJTIIGC8Y1R12" }, "entitlement_groups": [{ "group_id": "market-data-tier-2", "entitlements": [{ "entitlement_type": "DATA_ACCESS", "scope": { "asset_classes": ["EQUITY", "FIXED_INCOME"], "data_classifications": ["CONFIDENTIAL"], "redistribution": "DISPLAY_ONLY" }, "constraints": { "rate_limit_per_minute": 120 } }] }]}
AIGF’s MI-16 (Preserving Source Data Access Controls) requires that data provenance and access restrictions be tracked when agents process information. Entitlement Interchange makes those restrictions portable: when your agent pulls data from a counterparty, the entitlement envelope travels with it, machine-readable, enforceable at the next boundary.
Conjunctive and disjunctive grouping modeled on Bloomberg, FactSet, and LSEG data licensing, with a redistribution enum (PROHIBITED, DISPLAY_ONLY, DERIVED_ONLY, FULL) that directly addresses the data vendor governance problem: when your agent pulls Bloomberg data, can it pass that data to a downstream agent? The answer varies by contract, by data type, by counterparty. The schema makes the answer machine-readable.23
Liability Metadata: allocates responsibility across multiple parties in a multi-hop chain.
{ "liability_model": "PROPORTIONAL", "parties": [ { "organization_lei": "5493001KJTIIGC8Y1R12", "role": "ORIGINATOR", "responsibility_scope": { "governance_certification_level": "TIER_3_FULL", "liability_cap_usd": 10000000 } }, { "organization_lei": "HWUPKR0MPOU8FGXBT394", "role": "EXECUTOR", "responsibility_scope": { "governance_certification_level": "TIER_1_BASIC" } } ], "default_assignment": { "rule": "PROPORTIONAL_BY_CERTIFICATION" }}
AIGF’s MI-7 (Legal & Contractual Frameworks) addresses liability allocation for AI agent actions, but only bilaterally and only within the enterprise context. Liability Metadata extends that allocation into multi-party chains where three or more independently governed firms interact: the scenario AIGF identifies as a risk but does not provide a format for.
Phased adjudication reflects where the industry actually is: ISDA-analog bilateral agreements in years 1 to 2, because the audience lives in a world of bilateral contracts. Basel peer-monitoring patterns for consortium governance in years 2 to 4. Automated adjudication for routine cases beyond year 4. Proportional liability flows toward weaker governance posture at the relevant hop. This is an EMV-inspired mechanism where governance_certification_level determines which counterparty absorbs risk. The same logic that shifted fraud liability from issuer to merchant when merchants failed to adopt chip-and-PIN applies here: if your agent lacks ISO 42001 certification and the interaction fails, you absorb a larger share of liability.24
Governance Hop Record (GHR):, the multi-hop audit chain, provides chain integrity across delegation hops.
{ "chain": { "actor_lei": "5493001KJTIIGC8Y1R12", "hop_index": 1, "parent_hash": "a1b2c3d4e5f6...sha256-of-hop-0", "chain_id": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "total_hops": 3 }, "liability": { "model": "PROPORTIONAL", "attestation": "Meridian Capital accepts proportional liability for this hop" }, "compliance_event": { "actor": "research-agent-7", "action": "DATA_ACCESSED", "target": "bloomberg-mcp-server", "timestamp": "2026-04-28T14:32:07.891Z", "authority_basis": "urn:afix:entitlement:grant-4a2b", "outcome": "COMPLETED" }, "compensation": { "type": "REVERSAL", "timeout": "PT30M" }}
AIGF’s RI-28 (Multi-Agent Trust Boundary Violations) identifies chain-reaction compromise across agent networks as a key risk, but its mitigation is isolation: containment after the fact. The GHR provides provenance instead. A tamper-evident record of every institutional boundary the governance chain crossed, enabling reconstruction rather than just containment.

Each hop carries the acting institution’s LEI as a required field. Not an agent identifier, an institutional one, because liability is institutional. The correlation key is LEI:chain_id:hop_index: LEI identifies the institution, chain_id (a SWIFT UETR, Unique End-to-end Transaction Reference, analog) identifies the governance chain, hop_index sequences hops within it. Hash-linked entries (SHA-256 parent_hash) create a tamper-evident chain. AFIX provides chain integrity, not truth-of-claims verification. Certification claims must be validated against authoritative sources (GLEIF API for LEI, ISO registrar for 42001 status) at policy-engine evaluation time, not schema validation time. GLEIF LEI lapse rates run 15 to 20 percent; trusting a schema field over an API call is how stale governance metadata becomes a false assurance.25
I caught a design flaw during stress-testing: an A2A-specific field (ap2_mandate_ref) in the base Agent Card schema violated protocol agnosticism. It now lives exclusively in an A2A domain extension, accessed via authorization._ext_refs in Compliance Events. MCP-only deployments never encounter it. The schemas are published and linked from each component description above.
Binding AFIX to A2A & MCP
AFIX’s governance schema is protocol agnostic and can be applied to different enforcement mechanisms. How identical interchange metadata behaves across two fundamentally different protocol architectures was my primary concern while researching and coming up with the AFIX proposal. The schema components have analogues in FIX and FHIR. The regulatory story has context in the EU AI Act and ISO 42001. But in my research, I did not find any documentation or evidence of how any other single governance format binds to both A2A and MCP, and documents where the enforcement is equivalent, and where it is not.

MCP Binding: Where Financial Services Starts
MCP is where cross-enterprise agent interactions are actually happening in financial services today. Bloomberg AI Ready Data, FactSet AI Data Mesh, LSEG Trusted AI Ready Content: the tools that sell-side and buy-side firms use daily are MCP tools. With 97 million npm downloads and growing, MCP’s adoption in financial services is not theoretical.26
AFIX binds to MCP through two mechanisms.
The primary binding uses SEP-2133, MCP’s formal extension framework, shipped, Final status, not a roadmap item.27 AFIX would register governance capabilities using reverse-domain identifiers under the adopting organization’s namespace (e.g., finos.org/afix-governance if adopted as a FINOS Community Specification, or qball-inc.com/afix-governance under the current repository owner). At initialization, client and server negotiate governance extensions bilaterally. Servers can reject non-compliant clients. This is connection-level governance, mandatory enforcement, equivalent in strength to A2A’s extension negotiation.
// SEP-2133 extension declaration — server announces AFIX governance as required{ "capabilities": { "extensions": { "finos.org/afix-governance": { "version": "1.0.0", "components": ["agent-card", "compliance-event", "entitlement", "liability"], "required": true } } }}
The fallback binding uses _meta field conventions on every CallToolRequest and CallToolResult: backward compatibility for servers that have not yet adopted SEP-2133. The governance metadata degrades gracefully rather than breaking the interaction entirely.
// _meta fallback — AFIX governance metadata rides on a standard MCP tool call{ "method": "tools/call", "params": { "name": "bloomberg_reference_data", "arguments": { "security": "AAPL US Equity", "fields": ["PX_LAST", "VOLUME"] }, "_meta": { "finos.org/afix/agent-card": { "organization_lei": "5493001KJTIIGC8Y1R12", "agent_id": "research-agent-7", "agent_card_uri": "https://agents.example.com/.well-known/afix-agent-card.json" }, "finos.org/afix/compliance-event": { "event_id": "evt-aabb1122-3344-5566-7788-99aabbccddee", "event_type": "DATA_ACCESSED", "timestamp": "2026-04-28T14:32:07.891Z", "actor": { "agent_id": "research-agent-7", "organization_lei": "5493001KJTIIGC8Y1R12" }, "target": { "agent_id": "bloomberg-mcp-server", "organization_lei": "HWUPKR0MPOU8FGXBT394" }, "action": { "action_type": "REFERENCE_DATA_QUERY", "risk_classification": "LEVEL_4_SAFE" }, "authorization": { "status": "AUTHORIZED" }, "outcome": { "status": "SUCCESS" } } } }}
Gateway enforcement supplements both at the per-request level. The gateway ecosystem for MCP is production-ready. Cloudflare’s MCP Server Portals provide the most fully realized implementation: identity enforcement via Cloudflare Access, tool-level allowlisting per portal, DLP (Data Loss Prevention) scanning via Gateway body inspection, centralized audit logging with SIEM export via Logpush, and a shadow MCP detection layer that monitors corporate traffic for unauthorized agent protocol usage.5 Kong and Apigee offer MCP-specific gateway infrastructure with identity, ACLs, rate limiting, and audit logging.4 No equivalent A2A gateway ecosystem exists yet.
An AFIX-compliant deployment adds a structured Compliance Event to _meta before the gateway. The gateway’s existing logging captures the governance record alongside its native telemetry. No new infrastructure required. The governance metadata rides the enforcement infrastructure that firms are already deploying.
A2A Binding: The Fuller Implementation
A2A provides richer governance infrastructure at the protocol level. Five AFIX extensions register in the Agent Card’s extensions[] array with versioned URIs, four marked required: true.28 Non-compliant clients are rejected before task creation. That is structural enforcement at the protocol layer, not policy configuration at the gateway layer.
// A2A Agent Card — AFIX extensions declared in capabilities{ "name": "Meridian Trade Reconciliation Agent", "provider": { "organization": "Meridian Capital LLC" }, "capabilities": { "extensions": [ { "uri": "https://finos.org/afix/v1/agent-card", "required": true, "params": { "organization": { "legal_name": "Meridian Capital LLC", "lei": "5493001KJTIIGC8Y1R12" }, "regulatory_jurisdiction": ["SEC", "FINRA"], "authorized_actions": { "categories": ["TRADE_RECONCILIATION", "SETTLEMENT_QUERY"], "authority_thresholds": { "max_notional_usd": 50000000 } } } }, { "uri": "https://finos.org/afix/v1/compliance-event", "required": true }, { "uri": "https://finos.org/afix/v1/entitlement", "required": true }, { "uri": "https://finos.org/afix/v1/liability", "required": true }, { "uri": "https://finos.org/afix/v1/ghr", "required": false } ] }}
Four attachment points provide fine-grained governance context: Agent Card (identity and posture), per-message message.metadata (Compliance Events), per-task task.metadata (entitlements, liability), and hop-level GHR entries. The message is the audit trail. Reconstructing governance requires reading the messages, nothing else. A2A v1.2’s Signed Agent Cards add JWS-signed verification over JSON Canonicalization Scheme, enabling cryptographic domain verification: a firm can prove its Agent Card was not tampered with in transit, which is a precondition for any governance metadata exchange where the stakes are real.6
The Narrowed Asymmetry
Connection-level enforcement is now equivalent between the two protocols. SEP-2133 gave MCP the same bilateral negotiation capability that A2A had from its initial design. The remaining asymmetry is real but bounded: three specific gaps, not unamanageable like a fundamental architectural mismatch.
First: Per-request metadata granularity. A2A has four attachment levels. MCP has two (request and response). Intermediate states, partial results, and streaming responses lose governance context in MCP. For most advisory and research workflows, this does not matter. For multi-step agent chains with governance checkpoints at each intermediate step, it creates blind spots.
Second: Multi-hop propagation. A2A’s GHR appends to message metadata at each hop natively. MCP has no native multi-hop support. The orchestrator must propagate _meta between point-to-point calls manually. If the orchestrator drops governance metadata, the chain breaks silently. This is the same class of problem the W3C faced with distributed trace context propagation, and the solution will likely follow the same path: explicit propagation requirements with conformance tests. But today, it is a structural limitation of the protocol pair, not a manageable engineering detail.
Third: Audit trail location. A2A self-documents governance. The message log is the complete audit trail. MCP governance requires correlating protocol traces, gateway logs, and IdP (identity provider) logs across independent systems. Cloudflare’s architecture illustrates this concretely: reconstructing the complete governance picture for a single agent interaction requires correlating entries across Cloudflare Access logs for authentication, Gateway logs for shadow detection and DLP, portal logs for tool invocation, and AI Gateway logs for cost controls.5 It works. It is not self-contained.
Same schema, equivalent connection-level enforcement, different per-request granularity. The distinction is between compiled type safety and runtime validation: both produce correct outcomes, through different mechanisms and with different failure modes.
Enforcement Latency
The schema is identical regardless of enforcement mode. What differs is the validation architecture, and this matters in financial services where system classes span six orders of magnitude in latency tolerance.
Real-time systems (trading, pricing, payments) pre-validate governance at connection or session establishment and operate under cached entitlement tokens with TTL (time-to-live). The fast path is a lightweight token check, not full schema validation per request. Advisory and settlement systems (research queries, post-trade workflows, compliance reporting) use inline gateway validation per interaction. They can afford the latency and benefit from per-interaction audit granularity.
AFIX targets governance at the agent interaction tier: advisory, research, compliance, settlement. Execution-tier workflows (matching engines, order routing at microsecond latency) operate below the governance interchange layer and are governed by existing protocol-specific mechanisms: FIX compliance fields, exchange-mandated risk checks. Conflating the two tiers is the fastest way to get dismissed by a trading technologist, so the distinction was worth being explicit about.
The Aggregator Question
Cross-firm governance observation, chain correlation, and entitlement revocation broadcast all converge on a single architectural question:
Who operates the correlation infrastructure?
This is not an implementation detail to resolve later. Whoever operates the correlation infrastructure becomes the de facto governance authority, as SWIFT gpi and DTCC’s Trade Information Warehouse demonstrate in their respective domains.29 I could thik of three candidate models, each with distinct tradeoffs:
- A FINOS-operated aggregator offers neutrality and open-source governance but has no existing infrastructure for operating financial services correlation at scale.
- A SWIFT-operated aggregator uses decades of existing infrastructure and institutional relationships but carries centralization risk and SWIFT’s own governance agenda.
- A distributed peer-to-peer model eliminates central points of failure but makes chain correlation across firms an unsolved distributed systems problem, and distributed consensus mechanisms have not demonstrated the throughput characteristics that financial services governance observation would require.
The broader financial community must choose who operates the governance observation and enforcement. That choice determines whether AFIX or any other protocol like it becomes an industry standard or a bilateral curiosity. The precedent from every comparable infrastructure decision in financial services suggests that avoiding this question does not prevent a default answer from emerging; that would be the “glass is half-full” way of looking at it.
From Schema To Pilot
Schemas are claims. Pilots are evidence. The Agentic Cross-Enterprise Governance Pilot (ACGP) is designed to answer a single question:
Can governance metadata propagate correctly across firm boundaries using A2A and MCP as they exist today?
The pilot below has not been executed. It is a proposed design experiment: a minimum viable experiment that any three willing firms could run with the published schemas and existing protocol infrastructure.

The scenario calls for three firms and one research workflow. Firm A is a sell-side institution running an orchestrator agent that delegates research tasks across counterparties. Firm B is a data vendor exposing market data services via MCP with governance middleware. Firm C is a buy-side firm consuming enriched research output and needing an auditable governance trail for EU AI Act regulatory reporting. None of these firms would share internal infrastructure. They would share a schema vocabulary.
Phase 1: Discovery.
- Firm A queries Firm B’s AFIX Agent Card via
.well-knownendpoint or MCP tool discovery. - The response would carry Firm B’s Legal Entity Identifier (LEI), ISO 42001 certification tier, authorized data categories, and entitlement requirements.
- Firm A’s policy engine evaluates whether Firm B’s governance posture meets its counterparty standards. The same class of pre-trade credit check that exists in every electronic trading relationship, applied to agent interactions instead of order flow.
Phase 2: Negotiation.
- A2A path: AFIX extensions negotiated via Agent Card header handshake, four required extensions declared.
- MCP path: SEP-2133 extension registration at connection initialization, with
_metafield fallback for counterparties that have not adopted the extension specification. - Both paths are exercised in parallel because real-world adoption will not be uniform. Some firms will adopt SEP-2133 in months, others in years.
Phase 3: Execution with Governance Propagation.
- Firm A creates a Governance Hop Record (GHR) at chain origin, generating a
chain_id, a SWIFT UETR analog for agent governance. - Firm B executes the data retrieval, emits a Compliance Event recording the action, and appends its own GHR entry with its LEI as
actor_lei. - Firm A forwards the enriched output to Firm C, appending the final GHR hop.
- At each transition,
governance_certification_levelcomparison would enable proportional liability attribution. A TIER_3_FULL certified firm assumes different liability weight than a TIER_1_BASIC counterparty, mirroring the liability shift mechanism in Compelling Evidence 3.0 from the payments domain.30
Phase 4: Audit Reconstruction.
- Firm C’s compliance team pulls the GHR chain by
chain_id. Three hops, institutional identity verified at each, Compliance Events at each transition boundary. - The governance trail is self-contained. Firm C reconstructs complete provenance without trusting Firm A’s internal logs.
- This follows the bilateral metadata exchange pattern that Stripe’s Enhanced Issuer Network proved at payments scale: cross-firm risk signals that travel with the transaction, not through a separate reporting channel.30
Phase 5: Failure Case.
- Firm B’s agent attempts an action outside its entitlement scope. Say, redistributing derived analytics that the Entitlement Interchange restricts to
NON_DISPLAY_OK. - The entitlement check fires a denial. A Compliance Event with
DENIEDoutcome is emitted and pushed to the governance observer before the violation can propagate. - This mirrors the pre-filing evidence pattern that Verifi and Ethoca integrations use to intercept payment disputes before they materialize, reducing dispute rates by 51% in Stripe’s implementation.30
- The governance layer is designed to prevent unauthorized actions, not just log them.
What the ACGP deliberately scopes out:
- Automated liability adjudication (Phase 1 is ISDA-analog bilateral only)
- Aggregator-scale event streaming (a Phase 2 problem)
- Cross-jurisdictional regulatory mapping (a separate workstream beyond pilot scope)
The pilot’s success criterion is narrower and more falsifiable: governance metadata propagates intact across three firm boundaries through both protocol transports. If that works, everything else is an application layer on top of a working interchange.
The first-adopter incentive structure mirrors what drove FIX Protocol adoption in 1992. Salomon Brothers and Fidelity did not adopt FIX because an industry body told them to. They adopted it because they needed to reduce trade communication costs between two specific firms, and everyone else followed when the bilateral standard proved cheaper than the bilateral alternative.31 A data vendor benefits from standardized governance because it replaces per-client governance middleware integration with a single schema vocabulary. A buy-side firm benefits because it gains auditable cross-firm governance trails that satisfy EU AI Act Article 12 record-keeping requirements without building bespoke integrations with every counterparty.
The detailed pilot design with example JSON payloads at each phase is published at: AFIX Research Pilot
An Earnest Appeal
Independent governance programs are underway at every major firm at the moment with framework-level coordination through CC4AI and ISO 42001. But there is no evidence of any focus on governing interchange.
The EU AI Act enforcement deadline lands in August 2026. ISO 42001 adoption is accelerating across every tier-1 institution surveyed in this research. And every firm that deploys agents across enterprise boundaries without a shared governance vocabulary makes the eventual standardization harder, not easier, because each bilateral integration becomes a migration liability when the standard arrives.
AI compresses timelines. Infrastructure that took a decade to standardize in the trading era (FIX went from bilateral experiment to industry default in roughly eight years) will need to happen in half that window or less. Agent deployments are not waiting for governance to catch up. The gap between what firms are building internally and what exists for cross-firm interchange widens with every quarter.
The alternative to industry-led standardization is hyperscaler-led de facto standardization. Google has the protocol stack: A2A, significant MCP influence through the AI Alliance for Interoperability Foundation (AAIF), the Agent-to-Agent Profile (AP2), the Universal Commerce Protocol (UCP), and the platform infrastructure through Vertex AI to ship governance as a platform feature.32 Microsoft has published MCP governance guidance and operates Azure AI governance tooling. As I mentioned earlier, the industry needs to collectively answer this question:
Should Financial Services & Fintech define an industry-native agent interchange governance standard or inherit whatever Silicon Valley hyperscalers come up with?
AFIX is one proposal from one person’s research. It may not be the right one. But the evidence assembled across this research (eight firms independently building governance infrastructure that stops at the enterprise boundary, two protocol families converging on extension models that can carry governance metadata, a regulatory landscape that demands audit trails across firm boundaries) points to a coordination gap that someone will fill.
I propose the Fintech Open Source Foundation (FINOS) as the institutional home for this work, through its AI Readiness Special Interest Group (SIG) for several reasons: FINOS operates under an open-source model with Apache 2.0 licensing compatibility, hosts an existing financial services developer community through projects like FDC3 (Financial Desktop Connectivity and Collaboration Consortium) and Legend, and its Community Specification process provides a governance path that does not require corporate membership to participate.33
The alternative host is Agentic AI Foundation (AAIF), which now governs both MCP and A2A. Protocol proximity is an advantage, but concentrating governance standardization in the same foundation that controls the underlying protocols creates a structural dependency that financial services institutions have historically resisted.
The risk with FINOS is equally real: it has not previously hosted a wire-format specification of this kind. FDC3 is the closest analog, an interoperability standard for financial desktop applications, and it took five years to reach FDC3 2.0 with adoption still uneven. CC4AI’s scope is framework governance: risk taxonomies, control mapping, organizational maturity, not protocol-level interchange specifications. FINOS’s own AIGF demonstrates both sides of this: its 23 risks and 23 mitigations cover every governance category that matters (agent identity, audit, access control, liability) and every one of them stops at the enterprise boundary. AIGF is the policy layer. AFIX is the envelope that carries those policies across the boundary. They are complementary by design, not competing. But proposing FINOS as the home for a wire-format schema is asking the foundation to operate in a mode it has not operated in before.34 I specifically chose to propose FINOS here because open governance matters more than institutional precedent. But the choice is the community’s to make; time will tell.
I’ve published all the schemas and the research methodology is open. Every source is cited, every assumption was stress-tested to the best of my abilities, and every counterargument built at its strongest within the scope of my expertise. Now it is up to the practitioners. Fork the schemas. Challenge the research. Adapt them to your stack, your regulatory jurisdiction, your counterparty relationships. Let me know where I am wrong and what can be improved. The full evidence chain (stress-tests, steelmanned counterarguments, divergent explorations, design decisions with rationale) is published alongside the schemas at github.com/QBall-Inc/afix.
The coordination layer starts when the second firm adopts the same vocabulary.
AFIX Documentation
| Resource | Description |
|---|---|
| AFIX Repository | Full specification, schemas, research methodology, and pilot designs |
| FS Agent Card Schema | Organizational identity, governance posture, authorized actions, and escalation chain |
| Compliance Event Schema | Universal audit primitive with six-field interoperability core and regulatory extension tier |
| Entitlement Interchange Schema | Cross-firm data and service access controls with redistribution governance |
| Liability Metadata Schema | Multi-party responsibility allocation with EMV-inspired proportional liability |
| Governance Hop Record Schema | Tamper-evident multi-hop audit chain across institutional boundaries |
| ACGP Research Pilot | Three-firm research workflow pilot with five-phase governance propagation (referenced in article) |
| ACGP Commerce Pilot | Consumer purchase lifecycle pilot exercising AFIX alongside AP2, UCP, and TAP protocols |
| Research Corpus | Stress-tests, steelmanned counterarguments, divergent explorations, and design decision rationale |
Sources
- Bloomberg LP, “Closing the Agentic AI productionization gap: Bloomberg embraces MCP,” bloomberg.com, 2026, bloomberg.com/company/stories.
- FactSet, “Enterprise MCP Part 3: Security and Governance,” FactSet Insight, 2026, insight.factset.com.
- LSEG, “Scaling AI in Financial Services with LSEG’s Trusted AI Ready Content and MCP,” lseg.com, 2026, lseg.com.
- Kong Inc., “Kong Introduces MCP Registry in Kong Konnect,” PR Newswire, February 2026, prnewswire.com; Kong Inc., “Introducing MCP Tool ACLs,” konghq.com, konghq.com/blog; Google Cloud, “How to secure your remote MCP server on Google Cloud,” cloud.google.com/blog.
- Goldberg, S., Carey, M., Anguiano, I., “Scaling MCP adoption: Our reference architecture for simpler, safer and cheaper enterprise deployments of MCP,” Cloudflare Blog, 2026-04-14, blog.cloudflare.com/enterprise-mcp; “MCP Governance,” Cloudflare Developer Documentation, developers.cloudflare.com.
- Google Cloud, “Introducing Gemini Enterprise Agent Platform,” Google Cloud Blog, 2026-04-22, cloud.google.com/blog; “Agent Gateway overview,” docs.cloud.google.com; A2A Protocol Specification v1.2, a2a-protocol.org.
- Pusukuri, K., “From Model Safety to Runtime Governance,” Oracle AI & Data Science Blog, 2026-04-23, blogs.oracle.com.
- AWS, “Policy in Amazon Bedrock AgentCore,” docs.aws.amazon.com; “Policy in Amazon Bedrock AgentCore is now generally available,” AWS, March 3, 2026, aws.amazon.com.
- OWASP Gen AI Security Project, “OWASP Top 10 for Agentic Applications for 2026,” genai.owasp.org.
- Anthropic, Claude Code hooks documentation: PreToolUse, PostToolUse, SessionStart, SessionEnd, SubagentStart/Stop, 2026.
- JPMorganChase, “2025 Investor Day Transcript,” May 19, 2025, jpmorganchase.com; JPMorganChase, “Teresa Heitsenrether — Leadership,” jpmorganchase.com; Tearsheet, “JPMorgan Chase’s Gen AI implementation: 450 use cases and lessons learned,” 2025, tearsheet.co.
- OpenAI, “Morgan Stanley uses AI evals to shape the future of financial services,” openai.com; Morgan Stanley, “Artificial Intelligence: Firmwide Team,” morganstanley.com; Son, H., “Morgan Stanley names head of artificial intelligence, Jeff McMillan,” CNBC, 2024-03-14, cnbc.com.
- BlackRock, “AI Labs,” blackrock.com/corporate/ai; BlackRock, “Stephen Boyd — Biography,” blackrock.com; IMD, “BlackRock — AI Maturity Index 2025,” imd.org.
- FINOS, “AI Governance Framework v2.0,” air-governance-framework.finos.org; FINOS, “Global Financial Institutions and Technology Leaders Collaborate Under FINOS to Launch Open Source Common Controls for AI Services,” June 2025.
- European Parliament, “Regulation (EU) 2024/1689 — Artificial Intelligence Act,” Articles 9-15 (high-risk AI system requirements), OJ L, 2024. Enforcement for high-risk obligations: August 2, 2026.
- ISO/IEC 42001:2023, “Information technology — Artificial intelligence — Management system,” ISO.
- European Parliament, “Regulation (EU) 2016/679 — General Data Protection Regulation,” Articles 44-49 (international data transfers), OJ L 119, 2016. Combined with EU AI Act Article 13 (transparency).
- FIX Trading Community, FIX Protocol specifications, fixtrading.org. ComplianceID (Tag 376), SolicitedFlag (Tag 377), Parties component block. Origin: Robert Lamoureux and Chris Morstatt, 1992 (Fidelity Investments and Salomon Brothers).
- HL7 International, “FHIR (Fast Healthcare Interoperability Resources),” hl7.org/fhir. Capability-based architecture, multi-transport binding (REST, Messaging, Documents, SMART on FHIR), formal extension mechanism. DSTU 1 published September 2013.
- RIXML.org, Research Standard and Interactions Standard documentation, rixml.org. Tiered adoption with minimum viable envelope; MiFID II compliance utility 17 years after initial publication.
- Practitioner observation and original design decision: tiered disclosure (public vs. permissioned layer) for commercially sensitive fields in Agent Cards. No tier-1 bank publishes trading authority thresholds to public endpoints.
- FIX Trading Community, FIX Protocol specifications (ExecutionReport fields, user-defined tags 5000+), fixtrading.org; HL7 International, FHIR AuditEvent R5 resource, hl7.org/fhir/auditevent.html; RIXML.org, Interactions Standard v2.0, rixml.org. Six-field convergence (actor, target, action, timestamp, authorization, outcome) is an original analytical finding.
- Bloomberg LP, “Closing the Agentic AI productionization gap: Bloomberg embraces MCP,” bloomberg.com; FactSet, “AI Data Mesh” product documentation; LSEG, “Trusted AI Ready Content” product documentation. Redistribution enum is an AFIX original design modeled on observed data licensing patterns.
- EMVCo, EMV Chip Specifications and Liability Shift framework (US effective October 2015). Proportional liability via
governance_certification_levelis an AFIX original contribution. - GLEIF, “LEI Statistics,” gleif.org. Approximately 2.7M LEIs issued; renewal lapse rates vary by jurisdiction.
- Anthropic, MCP adoption data; RedMonk, “Fastest adopted standard,” late 2025. 97 million monthly SDK downloads (Python + TypeScript combined).
- GitHub, “SEP-2133: Extensions framework for MCP (Final),” github.com/modelcontextprotocol.
- A2A Protocol, “Extensions,” a2a-protocol.org; A2A Protocol, “Specification v1.0.0,” a2a-protocol.org.
- SWIFT, “Swift GPI — Global Payments Innovation,” swift.com; DTCC, “DTCC’s Global Trade Repository,” dtcc.com. Central correlation infrastructure as de facto governance authority.
- Stripe, “Optimizing payments at scale: How Stripe applies AI across the payment lifecycle,” 2025, go.stripe.global (PDF). Compelling Evidence 3.0 liability shift, Enhanced Issuer Network bilateral metadata exchange, Verifi/Ethoca pre-filing evidence (51% dispute rate reduction).
- FIX Trading Community, “FIX Protocol specifications,” fixtrading.org. Origin: Robert Lamoureux and Chris Morstatt, 1992, bilateral protocol between Fidelity Investments and Salomon Brothers.
- Google, A2A Protocol, a2a-protocol.org; Google Developers Blog, “Under the Hood: Universal Commerce Protocol (UCP),” developers.googleblog.com; Google Cloud, “Gemini Enterprise Agent Platform and Agent Gateway,” Cloud Next 2026. AAIF governance of A2A and MCP under Linux Foundation.
- FINOS, “Community Specification License,” finos.org; FINOS, “Contribution and IP Policy” (Apache 2.0 requirement); FINOS, “FDC3 — Financial Desktop Connectivity and Collaboration Consortium,” fdc3.finos.org; FINOS, “Legend,” legend.finos.org.
- FINOS, “AI Governance Framework (AIGF) v2.0,” air-governance-framework.finos.org; FINOS Common Controls for AI (CC4AI), participants: BMO, Citi, Morgan Stanley, RBC, Goldman Sachs, Bank of America. 23 risks, 23 mitigations; all scoped to intra-enterprise governance. FDC3 chartered February 2018, FDC3 2.0 reached in 2022.