Mastercard publishes 249 APIs on the network. It scores 49.5 — a developing band — and it is the most interesting scorecard of this week’s profiles because of where the weakness sits.
The surface is fine
166 contracts, 100% callable as published. Twenty JSON-LD contexts. Two Spectral governance rulesets. A developer surface that includes a portal, engineering blog, signup flow, support, code examples and forty more resources.
Named APIs run across the payments estate: Bill Pay, Business Payment Controls, In Control for Commercial Payments, Commerce Pass, Community Pass Digital Identity and Acceptance, and a Universal Specification Submission API. Tagged areas cover Credit Cards, Digital Identity, Financial Services, Fraud Detection and Open Banking.
Nothing here is broken. Contract quality sits at 64.3 and governance at 58.3, both respectable.
The regulatory layer is where it falls down
Mastercard triggers the Banking & Open Finance regulatory regime in the Kin Score, matched via its tags. That regime scores 36.7.
This is a conditional facet — it only applies to providers operating inside a regulated regime, and it asks a different set of questions than the general rubric. Not is your OpenAPI valid, but does your published surface carry what a regulated financial API is expected to carry: consent flows, strong customer authentication signalling, data-sharing scope definitions, the artifacts an open-finance supervisor would look for.
A 36.7 on that layer, from one of the two companies that define global card rails, is the number worth sitting with. The general-purpose developer experience scores 41.3 and the regulatory posture scores 36.7 — for a business whose entire product is regulated money movement.
Agent readiness: 41.0
106 agentic operations, 76 acting, 1 human-in-the-loop.
One. On a payments surface.
The readiness dimensions present: spec presence, auth clarity, verified error semantics, documented rate-limit signalling. Absent: MCP server, Agent Skills, .well-known catalog, agent card, consent identity, dry-run mode, idempotency signalling, and event surface description.
Dry-run mode is the one that stands out here. For an API that moves money, the ability to say “show me what this would do without doing it” is not a nice-to-have — it is the primitive that makes agent-initiated payments testable. It is not present.
Neither is idempotency signalling, which for payments is the difference between a retried request and a double charge. Mastercard almost certainly implements idempotency; the point is that the published contract does not tell a client — or an agent — that it does.
The pattern
This is the recurring shape in financial services on the network: strong contract mechanics, weak regulatory-layer publishing, and near-zero agent-facing consent infrastructure. The specs are callable. The governance around who may call them, for whom, with what approval, lives outside the machine-readable surface.
Composite 49.5, trending up slightly at +0.7 since the previous scoring run.
Takeaway
249 APIs, every contract callable, twenty JSON-LD contexts — and a 36.7 on the banking regulatory layer with exactly one human-in-the-loop marker across 76 acting operations. Mastercard has built a well-formed developer surface and has not yet published the governance layer that its own regulatory position implies.
See the full profile at apis.io/providers/mastercard/.