The questions your risk committee will ask about CoreFi, with the evidence locations.
This page is written for risk and compliance teams preparing an internal vendor-risk discussion. It covers seven topics in the order a review typically runs: evidence, audit, human approval, data residency, model governance, incident response and operational resilience. Each section states the question, the answer and where the supporting artefact lives. It is designed to be printed and circulated.
One page for the discussion. Two references behind it.
CoreFi publishes its trust posture in three layers. The Trust Center describes how the platform is designed to support the frameworks our customers operate under: GDPR, PSD2, the EU AI Act and DORA, together with the responsibility model, the sub-processor summary and the evidence-pack request route. The Architecture reference shows where the institution's perimeter ends and CoreFi's begins. This page condenses both into the seven questions a vendor-risk review asks, and points to the artefact that answers each one.
Two facts frame everything below. CoreFi is the platform vendor; the customer holds the licence, owns the supervisory relationship and remains the regulated entity. And what we publish is intentionally conservative: the detailed documentation sits in an evidence pack shared under NDA, available on request through the Trust Center.
Seven topics, the control surface behind each, and where the evidence lives.
| Topic | Control surface today | Where the evidence lives |
|---|---|---|
| Evidence | Public summaries on this site; detailed documentation set maintained for customer due diligence. | Evidence pack under NDA, available on request; audit-log extracts on request. |
| Audit | Append-only case-level record per workflow covering human, API and agent actions; exportable. | Audit-log specification in the evidence pack; record exports through documented APIs. |
| Human approval | Approval shape declared per workflow: single approver, dual control, MLRO sign-off, treasurer authorisation. Monetary actions default to human approval. | Policy pack as a documentary artefact, available on request; reviewer decisions in the audit record. |
| Data residency | EU-resident by default; regional and single-tenant deployment available on request. | Data Processing Agreement; sub-processor summary on the Trust Center; named vendors in the evidence pack. |
| Model governance | Model registry with version, provider and intended scope; the audit log records which model produced each agent action. | Registry extracts and EU AI Act control mapping in the evidence pack, available on request. |
| Incident response | Severity classification, on-call rotation and a customer-notification commitment defined in the DPA. | DPA terms; post-incident pack with the relevant audit-log slice. |
| Operational resilience | Treated as an ICT third-party provider under the customer's DORA framework; BC/DR procedures documented. | DORA mapping, BC/DR procedures and responsibility matrix in the evidence pack, under NDA. |
"Available on request" means the artefact exists and is shared during a security review or under NDA; it is not a public download. Nothing in this table is a certification claim. Last updated: June 10, 2026.
What can the vendor actually show us, and under what terms?
- Is there a documentation set we can review before contract, or only marketing pages?
- Who handles the request, and how long does it take?
The public pages summarise the posture; the detail sits in an evidence pack shared under NDA with active buyers. It covers the sub-processor list with named vendors, the Data Processing Agreement template, the encryption and key-management architecture, the audit-log specification, the responsibility matrix, the incident-response playbook, business-continuity and disaster-recovery procedures, the DORA and operational-resilience mapping, and the current status of any independent attestations under way. Requests route to a security-cleared inbox, not the general sales queue, and we respond on a working-day cadence.
Evidence: the pack itself, requested through the Trust Center form. Audit-log extracts supporting a specific question are available on request as part of the security review.
Can you show me what the platform, and any AI agent on it, actually did?
- Is there one audit trail across human, system and AI actions, or separate logs to reconcile?
- Can the record be altered after the fact? Can we export it for our own auditors?
Every workflow writes a single append-only record: trigger, retrieved data, model identifier and context references, structured plan, policy decisions, API calls, side effects on the core, escalations and human approvals. The same record covers human operators, partner systems and AI agents, so an internal auditor or supervisor reviewing a case sees one chain rather than a model summary and a separate spreadsheet. The log is append-only; cryptographic hash-chain verification is wired today for AI Assistant tool calls, with per-workflow extension on the roadmap. Every record is exportable for internal review, external audit and supervisory requests.
Evidence: the audit-log specification in the evidence pack; record exports through documented APIs; the Trust Center AI-governance section shows the action log in product form.
Where does a human decide, and how is that decision recorded?
- Which actions can complete without a person, and who decided that boundary?
- Does the reviewer see what the model saw, or a summary of it?
Human-in-the-loop is configuration, not exception handling. Each workflow declares which steps require a human and what shape the approval takes: single approver, dual control, MLRO sign-off or treasurer authorisation. Monetary actions default to human approval. The reviewer sees the same context the agent saw, and a returned or overridden case carries a structured reasoning note into the audit record. The boundary itself is documentary: the policy pack that defines scoped permissions, limits and approval thresholds is written ahead of the workflow and is available on request.
Evidence: the policy pack, available on request; reviewer identities and decisions in the audit record; the workflow diagram below traces the reviewer lane end to end.
How an agent action passes through gates, reviewers and audit.
The diagram below is the same control path the Trust Center and the Architecture reference describe: a structured plan evaluated against policy gates before any side effect, a reviewer lane where policy routes a case to a human, and one append-only audit record covering both paths.
Where does our data live, and who else touches it?
- Does tenant data, including backups and the audit log, stay inside the EU?
- Which sub-processors see which data classes, and how are changes notified?
CoreFi is operated from the European Union. Production workloads, the primary database, the document store and the audit log run in EU regions, and tenant data stays inside that boundary unless the customer opts otherwise in writing. Standard Contractual Clauses or equivalent transfer mechanisms apply where any sub-processor sits outside the chosen residency boundary, and the transfer is logged. Single-tenant deployments, regional and Latin American deployment options, and institution-managed keys for single-tenant and customer-cloud shapes are available on request. Material changes to the sub-processor list are notified under the terms of the Data Processing Agreement.
Evidence: the sub-processor summary and data-inventory diagram on the Trust Center; named vendors per region, the DPA template and the key-management architecture in the evidence pack.
Which models run our workflows, and what happens when one changes?
- Is there a registry of models in use, with version and intended scope?
- Does the control framework change when the model provider changes?
Every model used in a workflow is registered with version, provider and intended scope, so model risk is reviewable per workflow. The audit log records which model produced each agent action, and changes to prompts, models or policy are versioned and reviewable. The control plane is model-agnostic: governed workflows run on Anthropic, OpenAI, Gemini, customer-hosted models or a mix, and the policy engine, audit log and approval flows do not change when the model swaps. These controls are designed to plug into the deploying institution's risk-management system, post-market monitoring, technical documentation and human-oversight obligations under the EU AI Act for high-risk-system deployments.
Evidence: model and prompt versions in the audit record; the mapping of specific EU AI Act articles to specific controls is available on request in the evidence pack.
When something breaks, who is told, when, and with what evidence?
- Is there a defined severity classification and a notification commitment we can hold the vendor to?
- Can the incident timeline be reconstructed independently of the vendor's narrative?
The Data Processing Agreement defines a severity classification, an on-call rotation and a customer-notification commitment for incidents affecting the confidentiality, integrity or availability of tenant data. Where personal data is affected, notification supports the customer's GDPR Article 33 obligations as the data controller. We do not publish a hard notification SLA on this page because the right SLA depends on the customer's own regulatory profile; the specific timelines are set in the customer's DPA and walked through during the security review. Incident timelines, affected workflows, model and reviewer activity during the incident window, and remediation actions are reconstructible from the append-only audit record, and the relevant slice is shared as part of the post-incident pack. Material incidents at a named sub-processor follow the same customer-notification path.
Evidence: the DPA terms; the incident-response playbook in the evidence pack; the post-incident audit-log slice.
Can we keep using this platform inside our own resilience framework?
- What goes into our register of information, and what is the exit strategy?
- Will the vendor participate in our resilience testing?
Customers in scope of DORA treat CoreFi as an ICT third-party service provider; whether and how DORA applies is the customer's determination with its own advisers. Business-continuity and disaster-recovery procedures are documented in the evidence pack, and participation in a customer's own resilience-testing exercises, including scenario walkthroughs of platform failure modes, is available on request. The sub-processor list is reviewed on a defined cadence as part of the resilience programme. On exit: customer, account, ledger and audit data are exportable in standard formats, and each adoption path on the Implementation page has a defined exit posture. The sub-processor summary, the contractual terms and the documentation set are built to support vendor due diligence, register-of-information and exit-strategy expectations for ICT third-party providers.
Evidence: the DORA and operational-resilience mapping, BC/DR procedures and responsibility matrix in the evidence pack, under NDA; the Trust Center DORA section for the pillar-by-pillar orientation.
The boundaries of this page, stated plainly.
CoreFi does not hold a banking, payments, crowdfunding or e-money authorisation, and nothing on this page transfers a regulatory obligation from the customer to CoreFi. "Designed to support" means the platform's control surfaces line up with the obligations the licensed customer carries; it is not a certification claim. CoreFi does not claim DORA certification, because no such certification exists. The platform's policy gates execute the customer's policies; they do not replace them. Nothing here is legal or regulatory advice: we describe how the platform supports the posture your compliance team has to defend, and your own advisers determine how the frameworks apply.
Bring this page to the discussion. Bring the evidence pack to the decision.
If the seven answers above hold up in your internal review, the next step is the written detail behind them: the evidence pack under NDA, or a live security review with the people who operate the platform.