The things a partner’s security and compliance review actually asks about, answered honestly, and only where true. Where something is not yet done, it says so. A partner who catches one inflated claim distrusts all of them, so there are none.
Credda’s standing refusals are, to a partner, guarantees: and every one is verifiable in source, which is rarer than it sounds. These are the answers a lender worried about fair-lending exposure most needs, and almost no vendor can give them.
One function writes scores. There is no manual-adjustment path, no appeal a person adjudicates, and a dispute’s outcome is itself deterministic. The lender’s first request is always a dial; the answer is always no.
AI in the platform is advisory only: it summarises and flags, and it never writes a score, resolves a dispute or renders a verdict on a person. An AI evaluate/recommend endpoint was proposed and refused. There is nothing to call.
No plan tier, and no amount of money, can move a score. Buying a higher plan raises your API limits, never your standing. Paid subjects map to the lowest trust weighting like everyone else.
An outcome only counts as verified evidence when someone OTHER than the subject confirmed it. The rule is enforced at every ingress in code, not policy, so a self-payment, a self-merge or a self-attestation is recorded but never verified.
The event ledger is append-only, with exactly one deletion path that asserts test-mode in every clause and is unit-test-locked. You can prove a record was not altered.
Disclosure is subject-initiated and scoped. Revoking a share token flips a published StatusList2021 bit, so even an offline verifier holding the credential sees the revocation.
A bias-free score is only credible if you can check it. Every one of these is public, live, and needs no API key, so you can audit any score against the model, and verify any credential against the published keys, entirely on your own.
The honest posture on the questions a SIG-Lite or CAIQ packet asks. “In progress” means exactly that, not a soft yes. The full, dated detail (and the items still open) lives in a vendor-security pack we share under NDA.
The scoring ledger is pseudonymous outcome events keyed by a platform-supplied external id: no names, no emails, no passwords. No card data, SSNs, government IDs, bank accounts, health data or biometrics, ever. Card data is Stripe-only and never reaches Credda.
TLS on every external interface, HSTS enabled, webhook targets must be HTTPS. The database and all backups are encrypted at rest with AWS KMS.
Least-privilege API-key scopes enforced on every route; API keys stored as SHA-256 hashes, never recoverable, never logged; atomic key rotation with a bounded grace window. Consumer accounts support TOTP MFA.
US-only (AWS us-east-1), no offshore processing. Consumer account deletion is a hard cascade; counterparty records about work someone else received survive by design, documented in the privacy policy.
An append-only audit log across many action types with full actor attribution (request id, platform, key mode, client IP), per-request metering, per-attempt webhook delivery logs, and request correlation ids.
Architectural, not a policy promise: AI output can never write a score, resolve a dispute or produce a verdict. The score is a deterministic pure function of an immutable ledger, and the formula is published.
Not yet certified. A readiness assessment against the AICPA Trust Services Criteria is complete and available under NDA; a Type II report is targeted for 2027. We treat SOC 2 as the evidence vehicle rather than answering 120-question spreadsheets one at a time.
Credda is not itself a GLBA financial institution on its current activities: it does not lend, broker, service, collect or transfer funds. As a service provider to a covered institution it is bound by contract to the Safeguards Rule the moment a partner brings it into scope, and it maintains a written information security program to § 314.4 on that basis.
Credda is not a consumer reporting agency, by design. Data is consumer-permissioned and consumer-initiated, and Credda contractually refuses to let its output be the credit or employment decision. This is a structural position, preserved by a clause Credda proposes. Where a partner does take a credit decision, /score/explain exposes ranked reasonCodes and /api/v1/reason-codes documents them, so the partner can meet its own ECOA / Reg B obligations.
Planned before the first partner contract. Compensating controls today: one shared input-validation schema on all write paths, parameterised queries throughout, a CSP with no unsafe-inline scripts, rate limiting, and a test-enforced no-eval boundary on the ingest mapping DSL.
Credda has had no known breach, and has self-identified and remediated several vulnerabilities before exploitation, including a raw OAuth-token exposure on two public routes, a payment-based verification bypass, and an auto-import stake-weighting arbitrage. Each is documented in the repository with a date. A company that audits itself, discloses what it finds, and marks what is not yet done is the thing a vendor review is actually looking for.
For the compliance pack, the SOC 2 readiness assessment, a DPA, or a pilot, reach the team through credda.io/security. We will lead with our open items and their remediation dates. Disclosing them is the point.
developers