generated: '2026-09-06' method: searched source: >- https://developer.equifax.com/documentation, https://www.equifax.com/about-equifax/security/, and live unauthenticated probes of https://api.equifax.com (2026-09-06). provider: Equifax providerId: equifax description: >- Standards and cross-cutting conformance for the Equifax API platform. Everything below is read from a public Equifax page or from a live probe; nothing is derived from a contract, because Equifax publishes no OpenAPI outside the signed-in developer portal. Entries marked conforms:false are honest negatives, not penalties. conformance: - id: oauth2 name: OAuth 2.0 (RFC 6749) conforms: true detail: >- client_credentials grant; Client ID + Client Secret + scope exchanged for a bearer Access Token at a per-environment token endpoint. The endpoint returns RFC 6749 error bodies ({"error":"invalid_request","error_description":...}). evidence: - https://developer.equifax.com/documentation - https://api.equifax.com/v2/oauth/token - id: oauth2-bearer name: OAuth 2.0 Bearer Token Usage (RFC 6750) conforms: true detail: Access Token carried on every request; HTTP 401 returned for missing/invalid tokens. evidence: - https://developer.equifax.com/documentation - id: oidc name: OpenID Connect conforms: false detail: >- No /.well-known/openid-configuration on any Equifax host (all 404). Machine-to-machine client_credentials only; no user-identity flow is published. evidence: - well-known/equifax-well-known.yml - id: oauth-server-metadata name: OAuth 2.0 Authorization Server Metadata (RFC 8414) conforms: false detail: /.well-known/oauth-authorization-server returns 404 on every host probed. evidence: - well-known/equifax-well-known.yml - id: rfc9457 name: Problem Details for HTTP APIs (RFC 9457) conforms: false detail: >- Errors use a proprietary JSON envelope {"efxErrorCode": ..., "description": ...}, not application/problem+json. evidence: - errors/equifax-error-codes.yml - https://api.equifax.com/ - id: rfc9116 name: security.txt (RFC 9116) conforms: false detail: >- No /.well-known/security.txt on any host, although Equifax does run a HackerOne VDP linked from its own footer. evidence: - well-known/equifax-well-known.yml - security/equifax-vulnerability-disclosure.yml - id: rfc8594 name: Sunset header / deprecation signalling (RFC 8594) conforms: false detail: >- A deprecation POLICY is published ("reasonable notice", immediate for security), but no Sunset or Deprecation response headers are documented. evidence: - lifecycle/equifax-lifecycle.yml - id: idempotency name: Idempotency keys for HTTP (draft-ietf-httpapi-idempotency-key-header) conforms: false detail: No idempotency key or replay-protection mechanism is published for any operation. evidence: - conventions/equifax-conventions.yml - id: versioning name: Explicit URI-path major versioning conforms: true detail: >- "We use the major version numbering scheme, which involves easily detectable patterns such as V1 or V2 in path segments to distinguish URIs by their version." Confirmed in a real published endpoint: https://api.equifax.com/business/tt/service/v1/inquiry evidence: - https://developer.equifax.com/documentation - https://assets.equifax.com/marketing/US/assets/developer-quick-start-guide.PDF - id: rate-limit-headers name: RateLimit header fields for HTTP (RFC 9745 / draft-ietf-httpapi-ratelimit-headers) conforms: false detail: >- 429 is documented as the exhaustion status, but no RateLimit-* or X-RateLimit-* header contract is published. evidence: - rate-limits/equifax-rate-limits.yml - id: openapi name: OpenAPI conforms: partial detail: >- Equifax DOES author OpenAPI — the UK portal user guide documents a "Download the OpenAPI specification" control that drops a YAML file, per API product — but the contract is behind the developer-portal sign-in and is therefore not publicly retrievable or machine-discoverable. evidence: - https://developer.equifax.co.uk/sites/uk/files/User%20Guide.pdf - https://developer.equifax.com/documentation - id: wsdl name: WSDL 1.1 / SOAP contract publication conforms: false detail: >- Equifax's publicly documented Teletrack endpoints ARE a SOAP 1.2 service — an unauthenticated request to https://api.equifax.com/business/tt/service/v1/inquiry on 2026-09-06 returned application/soap+xml with a soap-envelope Fault — but no WSDL is served: both ?wsdl and ?singleWsdl return that same fault rather than a contract. A SOAP surface with no retrievable WSDL is as unconsumable to a generator as a REST surface with no OpenAPI. evidence: - https://api.equifax.com/business/tt/service/v1/inquiry?wsdl - https://assets.equifax.com/marketing/US/assets/developer-quick-start-guide.PDF - id: tls name: TLS 1.2+ on all API hosts conforms: true detail: >- api.equifax.com negotiates TLS 1.2 with HSTS max-age=31536000; includeSubDomains; preload. developer.equifax.com and www.equifax.com negotiate TLS 1.3 with HSTS. evidence: - security/equifax-domain-security.yml compliance: - id: fedramp name: FedRAMP status: Ready for Agency Authorization evidence: https://www.equifax.com/about-equifax/security/ - id: nist-csf name: NIST Cybersecurity Framework status: assessed, score 4.4 (2025) evidence: https://www.equifax.com/about-equifax/security/ - id: third-party-certifications name: Third-party certifications and authorizations status: 52 claimed, not enumerated publicly evidence: https://www.equifax.com/about-equifax/security/ - id: fcra name: Fair Credit Reporting Act (FCRA) permissible purpose status: >- Regulatory regime governing the products, not a certification. Equifax gates production access behind a Go Live review, an IP allow-list and a contract precisely because permissible purpose must be established before a consumer file is pulled. evidence: https://developer.equifax.com/documentation domain_standard: found: false searched_for: - Metro 2 / CDIA credit data reporting format - FDX (Financial Data Exchange) - UK Open Banking / CDR consumer-permissioned data standards - ISO 20022 detail: >- No domain data standard is DECLARED by an Equifax contract we can read. Equifax's own published endpoints (Teletrack inquiry/furnishing) are proprietary JSON and XML payloads, and the per-product specifications are behind the portal sign-in, so a domain-standard signature cannot be confirmed or denied from the contract. Recorded as not-found rather than not-applicable: the credit bureau market DOES have furnishing standards, and a public contract would settle this in one read. No conformance is asserted without contract evidence. maintainers: - FN: Kin Lane email: kin@apievangelist.com