Nothing here asks you to trust us. It asks you to verify.
Coriqo keeps your bank's record of who decided, who knew and what was done about it. This page is about the part underneath: why that record still holds when someone who doesn't trust us checks it.
It answers the vendor security questionnaire your institution runs on every system that touches model risk data, in plain words: where Coriqo runs, how the record is protected from changes, how we handle AI and your data, and which regulations we map to. It also says plainly where an early-stage vendor stands today.
Your data stays in your environment. Coriqo never becomes a place your model risk data lives.
Before your security team approves anything new, it asks where model risk data will sit. Coriqo deploys into your private cloud or on your own servers, including air-gapped environments with no outbound network access. Connectors that read your existing systems are read-only by design. They look at your model registries, storage and pipelines, and the source system always keeps ownership of the data.
Private cloud / on-prem
Runs inside your infrastructure instead of a shared SaaS. Air-gapped deployment is supported, so Coriqo needs no outbound network connection to operate.
Read-only connectors
Connectors read from MLflow, Hugging Face, S3/Azure/GCS/NAS, CI/CD and cloud accounts. They never write back and never take ownership. Your source systems stay the source of truth for the underlying assets.
Separate database per customer
Each customer gets its own Postgres schema, not a shared table filtered by a customer ID column. We enforce the separation once, centrally, when a request comes in. We do not rely on every database query remembering to do it.
CSV / Excel import
Bringing your existing inventory in is a dry run first, then a commit. A second person approves it, and it can be rolled back with its dependencies in mind. It is not a one-way upload.
Live inventory feed
Loading your model inventory straight from a registry or warehouse is a labelled placeholder today, and the scan endpoint says so in its own response. The inventory comes in by CSV/Excel. Evidence is different: Evidence Connect pulls records from the systems it lists as Available.
Role-based access control
Eight roles, from read-only examiner access to organization admin. A consultant role can prepare work but cannot approve it. Segregation of duties is enforced by role.
Where a connected record actually goes.
If you connect Jira, GitHub or SharePoint, your reviewers will ask who handles that data on the way in and where the credentials are kept. Evidence Connect (see the product page) reads all three through a connector runtime that we operate. It is not a third party you send data to. It is software we run on your behalf, like any other part of Coriqo's application.
What each box stores
Your system keeps the row it always kept. The connector runtime stores the raw row and the source credential, kept separate for your account. Coriqo's application stores only the fields your approved mapping names, plus the sealed evidence record.
Read-only, both directions
The connector runtime never writes back to your source system. Coriqo's application never writes to the connector runtime's raw store directly. It reads only through the approved mapping.
Separate space per customer
Each customer's connections, raw records and credentials sit in their own separate space inside the connector runtime. It is the same idea as the separate database per customer above.
Retention
You set how long raw records are kept, per source. Deleting raw records once that period passes is not yet an automated job. We say so plainly rather than claim enforcement that isn't built.
Customer-hosted data plane
Running the connector runtime inside your own environment, rather than ours, is on the Institution roadmap. It is not available today. Ask us for the current status.
Don't take our word for it. Check it yourself.
An examiner, auditor or board member who relies on the record needs to know nobody changed it afterwards. Every governance event is added to a SHA-256 hash chain. That covers approvals, validation sign-offs, monitoring breaches and findings. Each link depends on the one before it, so if anyone alters a record afterwards, the chain breaks in a way you can see. You do not have to trust Coriqo's database to find out. Periodically, events are sealed into a Merkle tree and the checkpoint is signed with Ed25519. The result is a record of every model and agent decision that shows damage by itself. Nobody has to remember to check a dashboard. An examiner can download an inclusion proof and verify a single event with the public key alone. That works offline, with no Coriqo server and no network connection.
[PASS] Merkle inclusion proof — event proven in chain
[PASS] Ed25519 checkpoint signature — signed by coriqo-key-2026-01
RESULT: VERIFIED ✓ — no Coriqo server required
Hash-chained by design
Every change of state computes a SHA-256 hash over the event and the previous event's hash. We leave timestamps out of the hash on purpose, so a clock that runs fast or slow can never break the chain.
Merkle-sealed checkpoints
Events are sealed into a Merkle tree at each checkpoint. An examiner can verify one event with a short proof, without needing the entire history.
Ed25519-signed
Each checkpoint is signed. Checking it needs only the public key. It never needs a live connection to Coriqo, and it does not depend on our systems being up or trusted.
Public anchoring and timestamps
Every checkpoint is published to Sigstore's public Rekor transparency log and time-stamped by DigiCert's RFC 3161 time authority, on every plan. Both records sit outside Coriqo's control. A self-hosted bank with no internet access can turn them off.
Your people countersign
When someone at your bank signs in with a passkey, their phone or laptop also signs the newest checkpoint, with a key Coriqo never has. Changing the records it covers would then need a new signature from someone at your bank, and your examiner checks that against a keyring your bank keeps, not our copy. There is nothing to set up, and it works on every plan. A bank that wants to hold the signing key itself can keep it in its own AWS KMS; Coriqo then never holds the private key at all.
A witness that actually signs
A separate key, run by Coriqo, cosigns every checkpoint within minutes. It is labelled as ours and not passed off as independent. You can register your own witness key too.
Take the whole record with you
One export contains every checkpoint, key and event, and you can verify it offline at any time. It is the exit plan a bank's vendor-risk team asks for under DORA Article 28.
A certificate for any period
For a date range you pick, Coriqo issues one signed certificate that the record ran unbroken from the first checkpoint to the last. Quiet stretches are listed with the reason recorded for each. Your board or examiner can check it offline with the same verifier.
Sensitive reads are sealed too. Exports, searches through message archives, large pulls and reads by someone outside a model's owning team each add an event to the chain: who read, when and how many records. Opening an ordinary screen does not. Anyone who mines the archive leaves a trail of their own.
What this does not do: the hash chain makes tampering detectable, not impossible. A database administrator with direct access could still delete the most recent rows. That breaks the chain, but someone only notices when they run the verification check. So verification is a button in the product. It is also why Rekor anchoring exists as an option outside our control. Rows written before a hash-chain fix are marked as such. We do not claim they are verifiable.
Test the claim yourself. We publish a sealed bundle and the offline verifier that checks it, and we ask people to try to forge one that passes. If you break it, we publish the write-up under your name. There is no prize money. Break the seal, or read about the three we already found ourselves.
Our own suppliers, signed.
Every outside service that sees your data is listed below, in a file we sign with our own key. When the list changes we publish a new signed version and keep the earlier ones, so you can see what it said on any date. The signature check runs in your browser.
Signed with key . The same fingerprint is published as a DNS TXT record on coriqo.io (coriqo-vendor-key), so you can confirm the key is ours without relying on this page.
| Subprocessor | What it does | What it sees | Applies to | Region |
|---|
Version history
The AI keeps no data, cites your own records, and is never the actor of record.
Your staff, your board and your examiner need to see that a person made each decision in the record, and that the AI did not. Coriqo uses AI to draft. It never decides, and it never changes your permanent record unless a named person approves first. You can run Coriqo with every AI feature turned off and lose nothing else. We built it that way on purpose.
No training on your data
Your data is never used to train models. Each AI feature makes a one-off request through a single gateway and keeps nothing afterwards. There is no fine-tuning step.
Named-person approval required
No AI output enters the permanent evidence record unless a person approves it. The record always shows that person as the one who acted, never "AI."
Citation-grounded, ID-verified
AI answers are based only on your own stored records. We check every citation against real IDs in your data. If an answer cites something that does not exist, we reject it or try again, and you never see it. You can re-check any answer's citations against the sealed chain whenever you like, including that a cited event's hash still matches the record it names.
Metadata-only audit logging
We log AI feature use for audit, but only the metadata, never the message content. The log goes into the same hash-chained record as everything else.
Says when it can't answer
If no API key is configured, you see a clear "unavailable" message. You never get an invented answer in place of a missing one.
Committee minutes parsing
Of the AI features we have shipped, this one is the weakest on grounding. It turns free text into structured minutes, without the citation check the others have. Ask us about it directly if it matters to your evaluation.
Mapped to the frameworks your examiner or review committee already cites.
Coriqo supports some of what those frameworks ask for. The rest stays with your own compliance program. Coriqo does not read regulatory text and does not claim to. What it does is enforce the working practices these frameworks describe: segregation of duties, independent review and a record of evidence. It also tags findings against the frameworks they relate to. That tagging is a curated cross-reference that people review. It is not an automated legal interpretation.
| Framework | What Coriqo structurally supports |
|---|---|
| SR 26-2 | Model risk governance: a fixed lifecycle (draft → review → validated → approved → production → retired). The reviewer can never be the model's own owner, and the system enforces that. It gives you evidence of "effective challenge" without relying on someone to remember a policy. Whether an asset is a model under §II is recorded as a determination with the answers given, the outcome and the rule that produced it. The revalidation interval is held per model with a reason, because §V prescribes no frequency. §I is explicit that the guidance sets no enforceable standards and that non-compliance draws no supervisory criticism, so what Coriqo records is your framework and your reasoning, not a compliance verdict. |
| SR 26-2 footnote 3 · generative and agentic AI | The guidance excludes generative and agentic AI from its scope, and says the bank's own risk management and governance practices should determine the controls for what it doesn't cover. Coriqo records that scope decision. It then governs those systems against the AI requirement sets your workspace installs, NIST AI RMF and the EU AI Act below, rather than claiming SR 26-2 reaches them. |
| SR 11-7 · OCC 2011-12 (superseded) | Replaced by SR 26-2 on 17 April 2026, along with SR 21-8 for BSA/AML systems. Historical gaps stay tagged under the framework that was in force when they were raised, so an older finding still reads against the standard it was actually judged by. |
| FDIC / FFIEC | Examiner correspondence (Q&A threads, document exchange, findings) and one-button examiner packages give your examiner a self-contained, dated record they can verify independently. Nobody has to dig through email. |
| EU AI Act | Zero-retention AI handling, a human approval on every AI-assisted output, and an auditable record of who approved what. That is the transparency and human oversight the Act expects of high-risk AI use, and we apply it to Coriqo's own AI features. |
| NIST AI RMF 1.0 | The 19 Govern / Map / Measure / Manage categories are seeded as control objectives, so evidence and findings attach to a named category rather than a free-text label. This is the framework substrate the US healthcare AI governance stack sits on. |
| Joint Commission RUAIH | The five certification domains ship as a deterministic requirement checklist for clinical AI documentation, covering governance, data management, risk and bias reduction, monitoring and validation, and transparency and training. RUAIH certifies a health system's AI governance program, so these are the checks a vendor's documentation must satisfy for its customer to pass a domain. |
| ONC HTI-1 DSI | The predictive decision-support source attributes a developer has to publish per algorithm (purpose and intended use, risks and limitations, development details, demographic representativeness, bias management, validation), cross-referenced onto the RUAIH domains wherever both cover the same documentation gap. |
| 21 CFR Part 11 | An append-only, hash-chained event history with signatures anyone can verify independently maps to Part 11's expectations for electronic-record integrity and non-repudiation, for institutions where that framework is in scope. |
Note: this mapping is a cross-reference to help your team scope evaluation, not legal or regulatory advice. Your own compliance program is what evidences compliance. Coriqo provides the data structures and workflow discipline that make that evidencing possible.
We'd rather you find out now than during a questionnaire review after signing.
You are trusting us with the record your examiners will read, so you should know how young we are. Coriqo is an early-stage company working with design partners. The core governance, hash chain and AI safeguards are real and shipped. But we do not yet have the third-party attestations (independent audit reports) that a longer-established vendor would have. The full dated list goes further, including what we found while verifying our own claims.
Governance workflow, hash chain and Merkle checkpointslive in production
Separate reviewers, blocked self-approval, hash-chained events and Ed25519-signed checkpoints that anyone can verify are shipped and running today. They are not roadmap items.
Off-host backups and a tested restore pathlive
Encrypted database backups run nightly to a separate off-host bucket, and a monthly automated drill restores the newest one into a throwaway database. It checks that every customer's data and the hash chain survived. We treat a backup we have never restored as if it does not exist.
Scope determination and per-model validation cadencelive
The §II scoping determination and the per-model revalidation interval are both stored and audited. The overdue list already shows whether an interval was set by the institution or inherited from the platform's old 365-day default. You record both from the model's own page. A model nobody has scoped shows as unassessed, not as in scope.
SOC 2in progress
SOC 2 is in progress. We do not hold a SOC 2 report today, or any other third-party security certification, and we will not say otherwise on this site or in a questionnaire answer. Ask us and we will tell you where the period stands.
Live inventory feedv1 stub in code today
A live feed of your model inventory from a registry or warehouse is not built yet, and the scan endpoint labels itself a placeholder. Inventory import today is CSV/Excel, with a dry run and a second person's approval. Evidence from Jira, GitHub and SharePoint comes through Evidence Connect, which lists each system's real status.
Alerting and escalationlive
Alerts go to webhook, Slack, email, Teams, PagerDuty and Opsgenie, and escalate when nobody acknowledges them. When someone acknowledges or resolves an alert in Coriqo, the incident in your pager is acknowledged or closed too. Every step is sealed. Still not built: SMS, a PagerDuty or Opsgenie app, and on-call rotations of our own.
Customer basestated honestly
We are working with design partners at this stage. We will not publish a customer count or logos we can't stand behind, and we will not imply scale we don't have.
You choose where Coriqo runs. We don't lock you into infrastructure we don't control.
Your vendor-risk team has already approved the infrastructure you run. Adding Coriqo shouldn't send them back to the start. Coriqo's backend runs on Postgres with a separate schema per customer. It deploys into your private cloud or on your own servers. We chose that for buyers who need to keep model risk data inside their own boundary and their existing vendor-risk approvals.
PostgreSQL
A separate schema per customer, with no reliance on row-level filtering. We enforce the separation once, when a request comes in.
Your environment
Private cloud or on your own servers, including air-gapped. We do not ask you to trust a shared cloud that Coriqo runs.
WeasyPrint
Makes the PDFs for examiner packages on the server. If the PDF tool isn't installed, it falls back to structured JSON, so you never get a broken page.
Sigstore Rekor
Checkpoints can be published to the public Rekor log, which Coriqo does not control, for institutions that want that extra independence.
Off-host, drilled monthly
Nightly encrypted backups to a separate bucket with server-side encryption at rest; a monthly automated restore drill proves they actually restore.
We keep this section conservative on purpose. If a specific sub-processor or hosting detail isn't listed here, ask us directly rather than assume. Your actual footprint depends on where you choose to run Coriqo.
Need the full security pack?
The pack holds a completed vendor security questionnaire (SIG-lite or your own format), our hardening checklist, the findings we haven't closed yet and an architecture diagram. We send it after both sides sign a mutual NDA, which we send for e-signature. Follow-up questions go to someone who can speak to the code.
To check the copy we sent you, run shasum -a 256 on it and compare the result with this list. The top row is the current version.
| Issued | Version | SHA-256 |
|---|---|---|
| 2026-10-15 | 1 | 49b95fbec55413cb064a4465109ff870af61b34a6fbc7bd40b0490a3a3f6a84b |