Regulatory Posture
For providers in a regulated industry ONLY: does the API publish the consent, security, legal, and standards-conformance posture its regime demands? Consent-scoped authorization (OAuth/OIDC scopes), a published security + vulnerability-disclosure posture, terms/privacy as legal basis, and evidence of conformance to the industry's data standard. Not applied to unregulated industries — see the composite math note below.
How it is scored
18 checks worth 108 points, grouped by the artifact each one reads. A facet's sub-score is its awarded points normalized against the points that were actually applicable to that provider — a check needing an artifact the provider does not publish at all is N/A, and leaves both sides of the fraction.
regulatory| Check | Rule | Points |
|---|---|---|
| Consent-scoped authorizationPublished OAuth/OIDC scopes — the machine-readable expression of least-privilege, consented access every data-sharing regime is built on. The single strongest regulatory signal. | common[].type includes "OAuthScopes" OR a scopes artifact is present | 10 |
| Authentication model documentedA documented authentication/authorization model (OIDC, mTLS, PAR). A regulated API that will not say how it authenticates cannot be trusted to hold the line the regime draws. | common[].type includes "Authentication" or "OpenIDConnect" | 6 |
| Security posture publishedA published security policy or domain-security posture. Regulated data demands a stated, verifiable security stance, not an assumed one. | common[].type includes "Security" or "DomainSecurity" | 6 |
| Vulnerability disclosure programA VDP / responsible-disclosure channel. For a regulated provider this is table stakes, and its absence is a conspicuous gap. | common[].type includes "VulnerabilityDisclosure" | 6 |
| Terms of service (legal basis)Machine-findable terms establishing the legal basis for access — the contract a regulator expects to exist and be discoverable. | common[].type includes "TermsOfService" | 4 |
| Privacy policy (data handling)A published privacy policy stating how personal/consumer data is handled — the disclosure most regulated regimes require. | common[].type includes "PrivacyPolicy" | 4 |
| Compliance / certification disclosurePublished compliance, certification, or trust-center content (SOC 2, ISO 27001, PCI, regime attestations) — evidence the provider holds itself to an external standard, not just its own word. | common[].type includes "Compliance" or "TrustCenter" or "Trust" | 5 |
| Data-standard conformanceEvidence the API conforms to the industry's data standard (a named standard, conformance artifact, or a published vocabulary/JSON-LD context). In a regulated space, speaking the mandated shape is the difference between interoperable and merely present. | implements a recognized data standard — common[].type includes "Standard"/"Conformance", or a Vocabulary/JSON-LD context is published | 5 |
| Conforms to the standard named for its regimeThe provider conforms to the standard RECOGNIZED FOR ITS REGIME, resolved against the standards catalog: OBIE, the DSB Consumer Data Standards, FDX or Berlin Group for open banking; US Core / USCDI for health; ACORD, CIECA or CSIO for insurance; CAMARA or TM Forum for telecom; Green Button / ESPI or cds-energy for energy.This supersedes the generic check above in strength for a reason the banking quartet made plain: a `Standard` tag credits an intention, while naming the instrument credits a fact. It is also the check the insurance quartet needed to state its emptiest finding honestly — ACORD is live inside a machine-readable contract at exactly one company worldwide. | conformance/ declares conformance to a standard listed under the matched regime`s `standards:` — not merely a generic Standard tag | 8 |
| FAPI / hardened authorization profileThe security profile CDR, UK Open Banking and PSD2 actually mandate, beyond generic OAuth: the FAPI profile, pushed authorization requests, private_key_jwt client authentication, mTLS-bound tokens. Generic OAuth is table stakes; this is the stack the regime specifies. | conformance declares FAPI or FAPI 2.0, or auth artifacts document PAR, private_key_jwt or mTLS-bound tokens | 6 |
| Published consent modelA consent surface a machine can read. This is the structural gap the whole series found and the reason it is weighted where it is: in market after market whose entire premise is consumer consent, machine-readable consent ran in the single digits. A FHIR Consent resource is exposed by essentially nobody; insurance ran at 2.5% in the US and zero among every market's leaders, in the most personally-invasive data business in the economy.Weighted heaviest in insurance and telecom precisely BECAUSE no rule compels it there — where consent is unmandated its presence is a genuine differentiator rather than a compliance artifact. | a machine-readable consent surface — consent scopes, a FHIR Consent resource, a CDR consent artifact, or a documented consent/authorization model | 7 |
| Action / write surfaceThe regime is actionable, not read-only. An agent that can move money on an account is a different animal from one that can only read it, and the score should say so: the UK — which mandated payment initiation — scored 87% on idempotency, where read-only Australia scored 0%. | the contract exposes payment initiation, VRP, or another mutating regulated operation | 4 |
| SMART-on-FHIR configuration servedA served `.well-known/smart-configuration` with published SMART-on-FHIR scopes. The structural finding across all four healthcare markets: the security scopes often exist, but the smart-configuration is served almost nowhere — so the check has to weight a DISCOVERABLE, consent-legible surface rather than the mere presence of scopes somewhere in prose. | a .well-known/smart-configuration is served, or SMART scopes are published | 6 |
| PCI scope and strong customer authenticationPCI-DSS attestation or scope disclosure together with strong customer authentication (3-D Secure, PSD2 SCA). The two disclosures every payments regime is built on, and the ones a merchant's own auditor will ask for first. | PCI-DSS attestation or scope disclosure, plus 3-D Secure / SCA support | 6 |
| Machine-readable entitlement and redistribution termsEntitlement and redistribution terms in machine-readable form, plus MiFID II or exchange data-licensing disclosure. In market data the licence IS the product boundary, and a consumer who cannot read it programmatically cannot build against it safely. | redistribution / entitlement / data-licensing terms published as machine-readable data | 6 |
| Third-party certificationA certification issued and published by somebody other than the provider. Canada runs the only public, tiered insurance API certification programme in the world (CSIO) and it was invisible to the score — its own table lists the country's largest P&C insurer as Not Yet Rated while smaller competitors hold higher tiers, which is exactly the published signal a rubric should read.THE CAUTION THIS CHECK CARRIES, learned from real estate: RESO certification is real, independently tested and industry-mandated, and it is worth 2.0 points of measured difference — because all three certified organizations return 401 on the very contract they are certified against. A certification claim is credited here only alongside `servers_resolvable`; a badge for a document the consumer cannot fetch is not conformance. | a public, independently-issued certification is held and discoverable | 5 |
| CAMARA / network-API conformanceConformance to the network-API standards the sector actually built: CAMARA commonalities, the canonical API definitions, CIBA (the backchannel authentication flow CAMARA specifies for network authorization, found in 3 of 19 standards repositories and absent from both specs of the one exposure platform with a callable endpoint), and TM Forum Open API conformance — held widely by carriers who publish no network API at all. | an x-camara-commonalities version, /camara/ paths, CIBA support, or TM Forum Open API conformance | 6 |
| Mandate implemented, not merely claimedTHE LARGEST UNMEASURED EFFECT IN THE CATALOG, and the reason it lands in 0.6 rather than waiting. Across 95 energy organizations scored on a deliberately ruthless mandate ladder, a VERIFIED mandate was worth about twelve points of composite — live-implemented 42.2 against not-applicable 36.6 — while a CLAIMED-but-unverifiable mandate scored 30.4, BELOW the 30.2 of organizations under no obligation at all.That second number is the finding. Self-declared compliance is not merely uninformative, it is NEGATIVE signal, and any assessment that reads compliance pages instead of calling endpoints will rank the field backwards at the top. Compare RESO in real estate at 2.0 points: same question, two sectors, a six-fold difference in effect, because one mandate came with a public register and conformant discovery endpoints and the other came with a badge.The failure mode is already live here: two Ontario utilities present as Green Button compliant and cannot be verified, one because its onboarding host returns HTTP 200 for every path including invented ones, being a single-page-app catch-all. Without a verification state that provider scores as compliant. | the mandated surface is evidenced by a resolvable endpoint, register entry or conformant discovery document — not by a compliance page | 8 |
How the catalog distributes on it
Every one of the 9,494 providers this facet is scored on, bucketed by sub-score.
Top providers
The top 500 of 8,921 providers scoring above zero on this facet, ranked by facet sub-score, ties broken by composite.
The other 7 facets
github.com/api-evangelist/<provider>, and each check above names the exact artifact it
reads. Publish the artifact, open a pull request, and the next scoring run picks it up — no gatekeeping
and no fee. The full rubric is at apis.io/rating/, and
prioritized profiling
is the fast lane if you would rather have it done for you.
Scored on rubric v0.17.2 across 27,504 providers · lists rebuilt 2026-09-01 · capped at the top 500 per page.