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
32 checks worth 164 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 |
| Software bill of materialsAn SBOM. The CRA makes it a condition of placing a product on the EU market, and US federal procurement already asks for it. Machine-readable, cheap to publish, and almost absent across the catalog. Asked for by: EU Cyber Resilience Act; EO 14028 procurement. (roadmap#444) | common[].type includes "SBOM" | 4 |
| Declared support lifetimeA published support or security-update period. UK PSTI made this a condition of sale alongside a vulnerability-disclosure policy — mandated, cheap, machine-readable, and mostly missing, which is what a scored check should be aimed at. Asked for by: UK PSTI; CRA; Australia Cyber Security Act. (roadmap#444) | common[].type includes "SupportLifetime" | 4 |
| Accessibility conformance reportA conformance report (VPAT/ACR or equivalent). A provider shipping an embedded widget, hosted page or SDK component puts that artifact inside a customer's EAA/AODA compliance boundary; the report is standardised in form and almost never in developer documentation. Asked for by: European Accessibility Act; ADA Title III; AODA; Section 508. (roadmap#444) | common[].type includes "AccessibilityConformance" | 4 |
| Training-data summaryA public summary of training data. AB 2013 and the AI Act's GPAI duties both ask for one; it applies only where the provider declares an AI surface. Asked for by: California AB 2013; EU AI Act GPAI. (roadmap#444) | common[].type includes "TrainingDataSummary" | 4 |
| AI interaction disclosureA disclosure that the user is interacting with an AI system. Applies only where the provider declares an AI surface. Asked for by: EU AI Act Art. 50; Utah AI Policy Act. (roadmap#444) | common[].type includes "AITransparency" | 4 |
| Global Privacy Control honouredA statement that the GPC signal is honoured. Four US states now require a universal opt-out to be respected, and the signal is machine-readable by design. Asked for by: Colorado, California, Connecticut, Texas universal opt-out. (roadmap#444) | common[].type includes "GlobalPrivacyControl" | 4 |
| Data-subject request routeA documented route for access, deletion and portability requests. Required by GDPR and by twenty US state laws, and a route nobody can find is a route that does not exist. Asked for by: GDPR; UK GDPR; 20 US state privacy laws. (roadmap#444) | common[].type includes "DataSubjectRequest" | 4 |
| Subprocessor listA current subprocessor list. Art. 28 makes it a contractual duty and DORA and NIS2 both push it down the supply chain; it is the artifact a customer's own auditor asks for first. Asked for by: GDPR Art. 28; DORA; NIS2; DOJ bulk data rule. (roadmap#444) | common[].type includes "Subprocessors" | 4 |
| Data residency statementA statement of where data is stored and processed. The DOJ bulk-data rule made this a transfer question rather than a preference, and sovereign-cloud procurement asks it directly. Asked for by: DOJ bulk data rule; EU Data Act; sovereign cloud. (roadmap#444) | common[].type includes "DataResidency" | 4 |
| Incident notification commitmentA published incident-notification commitment with a timeframe. A customer subject to SEC Item 1.05, DORA or NIS2 inherits the obligation and cannot meet it without one from its vendor. Asked for by: SEC Item 1.05 flow-down; DORA; SOCI; NIS2. (roadmap#444) | common[].type includes "IncidentNotification" | 4 |
| Age assuranceAn age-assurance statement or mechanism. NOT YET GATED: the catalog has no derived consumer-surface signal, so this is scored only within an applicable regime rather than against every provider (see the applicability note beside NA_UNLESS_CHECK in score.rb). Asked for by: UK Online Safety Act; AU Social Media Minimum Age; app store accountability laws. (roadmap#444) | common[].type includes "AgeAssurance" | 4 |
| Notice-and-action mechanismA notice-and-action route for illegal content. NOT YET GATED, for the same reason as age assurance. Asked for by: EU Digital Services Act. (roadmap#444) | common[].type includes "NoticeAndAction" | 4 |
| Transparency reportA published transparency report. NOT YET GATED, for the same reason as age assurance. Asked for by: DSA; UK Online Safety Act. (roadmap#444) | common[].type includes "TransparencyReport" | 4 |
| Exit assistance / switching termsPublished switching and exit-assistance terms. The Data Act made egress and exit a regulated term of cloud contracts rather than a commercial courtesy. Asked for by: EU Data Act cloud switching. (roadmap#444) | common[].type includes "ExitAssistance" | 4 |
| 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 29,770 providers this facet is scored on, bucketed by sub-score.
Top providers
The top 500 of 27,068 providers scoring above zero on this facet, ranked by facet sub-score, ties broken by composite.
The other 8 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 the
Influence plan is the fast lane if you would rather
work your own listing through the API — remediation, projections and re-check requests.
Scored on rubric v0.23.0 across 29,770 providers · lists rebuilt 2026-10-09 · capped at the top 500 per page.