GDPR-aligned data handling
Lawful-basis declaration per workflow, data-subject-rights workflow, EU-resident default. Detailed control mapping is available on request in the evidence pack.
Proof / Trust Center
Built for the institutions our customers answer to.
CoreFi is the platform vendor behind agentic banking infrastructure operated by licensed banks, lenders and fintechs across Europe and Latin America. This page summarises how the platform is designed to support the regulatory frameworks our customers operate under, and where to ask for the deeper evidence pack.
Risk and compliance teams preparing an internal vendor review can start from the printable Regulator View.
Trust posture
Designed to support the frameworks that govern modern banking, payments and AI.
CoreFi is built as platform infrastructure for institutions that have to satisfy European data-protection, payments, operational-resilience and AI-governance expectations. The platform is governed by internal controls and external commitments to those customers; the customer remains the regulated entity before its supervisor. Nothing on this page implies CoreFi holds a banking, payments, crowdfunding or e-money authorisation.
PSD2-compatible workflow design
Strong customer authentication hand-off points, payment-initiation evidence capture, and reviewer approval gates designed to fit a PSD2-licensed deployer's own control framework. CoreFi does not act as a PSU or AISP/PISP; the customer holds the licence.
EU AI Act controls (high-risk posture)
Approval gates, audit trail, human-in-the-loop and model registry, mapped to the Act's split of duties: they support the deploying institution's human-oversight and usage-monitoring obligations and produce the logging evidence that provider-side risk management and post-market monitoring rely on. See the AI governance section below.
"Designed to support" means the platform's control surfaces line up with the obligations the licensed customer carries. It is not a certification claim by CoreFi. Independent evidence is available on request.
Responsibility model
CoreFi is the platform vendor. The customer remains the regulated entity.
Every supervisory conversation about CoreFi starts with the same question: who is responsible for what? The answer is contractual and stable across deployments. CoreFi provides and operates the platform; the customer holds the licence, owns the regulatory relationship and remains accountable to its supervisor. The allocation below is a summary; the binding version lives in the customer's agreements.
What CoreFi is responsible for
The platform: its security controls, availability against agreed SLOs, the sub-processor chain, the audit and export surfaces, and the evidence that those controls operate. CoreFi supports the customer's audits and supervisory requests with documentation and audit-log extracts.
What the customer is responsible for
The regulated activity: the licence and supervisory relationship, product decisions, credit and AML policy, customer due-diligence outcomes, regulatory filings and the end-customer relationship. CoreFi's policy gates execute the customer's policies; they do not replace them.
What is operated together
Incident handling, change management and audit support follow defined hand-off points set in the Data Processing Agreement and the service agreement: CoreFi detects, notifies and remediates at the platform layer; the customer assesses and reports at the regulatory layer.
Nothing on this page transfers a regulatory obligation from the customer to CoreFi, and nothing here is legal advice. The full responsibility matrix is part of the evidence pack, available on request under NDA.
Data residency
EU-resident by default. Regional deployment for institutions that need it.
CoreFi is operated from the European Union. Production environments and the primary data store run in EU regions, and tenant data, document store and audit log stay inside the EU boundary unless the customer opts otherwise in writing.
EU default
Production workloads, primary database, document store and audit log run in EU regions. Standard Contractual Clauses or equivalent transfer mechanisms apply where any sub-processor sits outside the chosen residency boundary, and the transfer is logged.
Regional / LATAM deployment
Single-tenant deployments designed to keep tenant data and processing in a Latin American region are available on request, scoped to the deploying institution's licensing footprint. Available regions are confirmed during the security review.
Single-tenant option
For institutions that require infrastructure isolation, CoreFi supports single-tenant deployments on the customer's elected hosting partner. Tenancy model, isolation boundary and key-management ownership are agreed during the security review.
Hosting partner names and the current sub-processor list are summarised in the section below and detailed in the evidence pack on request.
Evidence pack
The deep documentation sits behind a security-cleared request.
What we publish is intentionally conservative. The detailed evidence pack covers the sub-processor list with named vendors, the Data Processing Agreement template, 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. It is shared under NDA with active buyers. Use the form below to request it.
Evidence-pack requests route to a security-cleared inbox, not the general sales queue. We respond on a working-day cadence and confirm next steps before any document moves.
Sub-processors
Who touches tenant data, and in which role.
CoreFi publishes the categories of sub-processors that may process tenant data on behalf of the deploying institution. Named-vendor specifics, regions and processing purposes are kept current in the Data Processing Agreement and the evidence pack; this public summary is updated when categories change.
Cloud / IaaS
Compute, storage and networking for tenant environments. EU primary; regional deployment available on request. Named vendors per region are shared in the evidence pack.
Managed database & object storage
Primary data store, document store and backups. Hosted in the same region as the tenant deployment. Named vendors per region are shared in the evidence pack.
LLM model providers
Model inference for agentic workflows. CoreFi is model-agnostic and per-customer scoped; workloads route to provider-defined regions where per-region routing is available. The audit log records which model produced each agent action.
Email & transactional messaging
Operator notifications and reviewer alerts. EU-primary providers. Named vendors are shared in the evidence pack.
Form & lead intake
Public-website form intake only (no tenant data). EU-hosted. Used for partner applications and evidence-pack requests.
Observability & error tracking
Platform telemetry and error aggregation. EU-primary. Named vendors are shared in the evidence pack.
Material changes to this list are notified to customers under the terms of the Data Processing Agreement. Last updated: June 11, 2026.
Data inventory and egress
Four data classes. Five sub-processor zones. One residency boundary.
The /architecture security view answers who is responsible for what. The diagram below answers which data lives where, and which sub-processors see it. The two diagrams are complementary; they do not duplicate.
AI governance
Model risk, policy gates, human approval and audit exports, for every agentic workflow.
Agentic AI is treated like any other operator on the platform: scoped to a role, gated by policy before any side effect, logged into the same append-only audit record as human and API actors, and routed to a human reviewer when policy says so. The control surface does not change when the underlying model changes.
Approval gates before any side effect
The agent's structured plan passes through role-permission, customer-consent, transaction-limit, AML, sanctions and model-output guardrails before any API is called. A failed check stops the workflow; nothing reaches the core silently.
One audit record per workflow
Every workflow writes a single append-only record covering trigger, retrieved data, model identifier and context references, structured plan, policy decisions, API calls, side effects on the core, escalations and human approvals. 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.
Human-in-the-loop is configuration
Workflows declare which steps require a human and what shape the approval takes: single approver, dual control, MLRO sign-off, treasurer authorisation. Monetary actions default to human approval. The reviewer sees the same context the agent saw.
Model risk: registry & model-agnostic control plane
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. CoreFi runs governed workflows on Anthropic, OpenAI, Gemini, customer-hosted models, or a mix; the policy engine, audit log and approval flows do not change when the model swaps.
Under the EU AI Act's high-risk regime, obligations split between the provider of an AI system and the institution deploying it: the risk-management system, technical documentation and post-market monitoring sit primarily with the provider, while the deploying institution must assign and operate human oversight, use the system within its intended purpose, monitor its operation and retain the logs under its control. The controls above are designed to support those deployer-side duties and to produce the logging and monitoring evidence the provider-side processes rely on. Mapping of specific articles to specific controls is available on request in the evidence pack.
AI governance workflow
How every agent action passes through gates, reviewers and audit.
CoreFi is built so that an AI agent cannot take an action on the ledger without first passing the same policy gates a human operator would, and so that any decision the policy reserves for a human reviewer is routed to one, with two-eyes sign-off where the policy requires it. The diagram below traces a plan from agent proposal through gates, reviewer lane and audit.
Incident & disclosure posture
Documented in the DPA, evidenced in the audit log, available on request.
Detailed incident-classification thresholds, customer-notification commitments and supervisory-reporting hand-off points are documented in the customer-specific Data Processing Agreement and walked through during the security review. We do not publish a hard notification-SLA on this page because the right SLA depends on the customer's own regulatory profile.
What we commit to in the DPA
Defined severity classification, on-call rotation, and a customer-notification commitment for incidents affecting 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.
Evidence in the audit log
Incident timelines, affected workflows, model and reviewer activity during the incident window, and remediation actions are reconstructible from the append-only audit record. We share the relevant slice with the customer as part of the post-incident pack.
Vendor & sub-processor incidents
Material incidents at a named sub-processor that affect tenant data follow the same customer-notification path. The current sub-processor list is reviewed on a defined cadence as part of the resilience programme.
Specific notification timelines and disclosure commitments are set in the customer's Data Processing Agreement and available on request as part of the security review.
Operational resilience & DORA
How the platform maps to operational-resilience expectations.
Customers in scope of the EU's Digital Operational Resilience Act treat CoreFi as an ICT third-party service provider. The high-level mapping below shows where the platform supports each pillar of that relationship. It is orientation, not legal advice: whether and how DORA applies is the customer's determination with its own advisers, and the detailed control-by-control mapping is part of the evidence pack, available on request under NDA.
ICT risk management
Access controls, environment isolation, encryption in transit and at rest, and the append-only audit record give the customer's ICT risk framework concrete control surfaces to assess. Platform documentation for that assessment is available on request.
Incident classification & reporting
The severity classification, customer-notification commitments and post-incident evidence described in the section above are designed to feed the customer's own incident-reporting obligations. CoreFi notifies and evidences at the platform layer; the customer classifies and reports at the regulatory layer.
Resilience testing
Business-continuity and disaster-recovery procedures are documented in the evidence pack. Participation in a customer's own resilience-testing exercises, including scenario walkthroughs of platform failure modes, is available on request.
ICT third-party risk
The sub-processor summary above, the contractual terms in the service agreement and the DPA, and the documentation set in the evidence pack are built to support the customer's vendor due diligence, register of information and exit-strategy expectations for ICT third-party providers.
CoreFi does not claim DORA certification; no such certification exists. What we provide is the documentation and the control surfaces a financial entity needs to keep using the platform inside its own resilience framework.
Talk to the team
Take the platform that runs your customers' workflows through your supervisor's questions.
Two paths from here: a written evidence pack under NDA, or a live security review with the people who run the platform.