Dify for banks and financial services: what changes when the platform runs in your estate
Banks and other financial firms want LLM workflows and retrieval-augmented assistants, but they cannot let customer data, prompts, model choices and audit evidence drift outside their control. Self-hosting Dify addresses the first part of that problem: the platform runs in cloud accounts, data centers or an isolated network that your organization operates, so the prompt store, knowledge bases, conversation logs and metadata database sit where your data governance already applies. Dify is released under the Dify Open Source License, a modified Apache License 2.0, and its Community edition is free but limited to a single workspace. That limit matters for a bank that wants separate environments for business lines, model risk reviewers or customer-facing teams. The Enterprise edition adds SSO, multiple workspaces, advanced security, a commercial license and professional support, and it is custom priced, so the quote should follow from a written scope rather than a list price.
A cloud trial hides most of the decisions that a regulated deployment has to make on day one. In a self-hosted install, your team chooses the metadata database (PostgreSQL by default, with MySQL or OceanBase as options), the file storage backend, the vector store (Weaviate by default, with alternatives such as Qdrant or pgvector), and the secrets that protect the platform. The SECRET_KEY setting signs session cookies and JWTs and encrypts OAuth credentials, and changing it after deployment logs out all users, so its generation, storage and rotation process must be agreed before go-live. Workspace encryption keys can be stored locally or in Azure Key Vault. The SSRF_PROXY settings route outbound requests through a proxy that blocks internal and private address ranges. Confirm with your security team which of these controls fit your key management and network standards before the first build.
Before you commit to a design, ask your implementation partner and your Dify contact to confirm three points in writing: which edition and how many workspaces your target operating model needs, which Dify version and release cadence your change process can absorb (minor releases have arrived roughly monthly), and which Enterprise deployment pattern, including Kubernetes and the resource requirements in the Enterprise checklist, your operations team can run. These answers drive the scope, and the scope drives the cost. The sections that follow cover the regulatory expectations behind this design: model risk, audit trails, data residency, operational resilience and approved model providers.
Which financial regulations shape a Dify build and what each means for the design
This table maps each financial regulation or framework to the parts of a self-hosted Dify build it touches: apps, knowledge bases, model providers and admin access. Read each row as an obligation the institution must meet, then as a design decision Dify configuration has to support. These frameworks set obligations, and auditors or competent authorities decide whether the institution meets them.
| Framework | What it asks for | Effect on the Dify design |
|---|---|---|
| DORA Article 28(3) and register of information | A register covering all contractual arrangements for ICT services, including those supporting Dify. | Record the Dify deployment, its hosting provider, model providers, vector store and plugin sources as ICT arrangements. Confirm with your compliance team which entries the register must hold. |
| DORA Article 28(8) exit strategy | Documented, tested exit strategies and transition plans for ICT services that support critical or important functions. | Plan how apps leave Dify: DSL exports omit third-party API keys, knowledge base content and usage logs, so test a restore path for those separately. |
| DORA Article 30(2) contract terms | ICT contracts must state where services run and data is processed, give advance notice of changes and cover data return on termination. | Pin the hosting region, model endpoints and object storage location in the contract. Map each data store Dify uses (metadata database, file storage, vector store) to a stated location. |
| DORA Article 26(7) threat-led penetration testing | The only authority-issued attestation in DORA is that a threat-led penetration test met the requirements. | Scope prompt injection, agent sandbox and API exposure tests into the testing program. Confirm with your competent authority how a Dify deployment fits its TLPT approach. |
| PCI DSS v4.0.1 (where cardholder data is in scope) | Controls apply to systems that store, process, transmit or could affect cardholder data. Version 4.0.1 is the only active version. | Keep card data out of prompts, knowledge bases and logs unless the Dify environment is inside the cardholder data environment. Confirm scope with your QSA before connecting payment workflows. |
| SEC ICFR guidance (Release 33-8810) | IT general control areas for SOX 404 include program development, program changes, computer operations and access to programs and data. | Version and approve app changes, keep DSL exports under change control, and restrict console roles so workflow logic cannot change without a recorded approval. |
| FTC Safeguards Rule (16 CFR 314.4(c)(5)) | Multi-factor authentication for any individual accessing an information system, unless the Qualified Individual approves an equivalent control in writing. | Require MFA for Dify console and admin access through your identity provider. Document any written exception for service or break-glass accounts. |
| Swift Customer Security Controls Framework v2026 | Independent assessment of 32 controls (26 mandatory, 6 advisory), with annual attestation in KYC-SA for Swift users. | Apply only where Dify supports Swift-connected workflows. Map Dify hosting, access and key management to the relevant controls and confirm the scope with your Swift security officer. |
Which Dify modules, settings and integrations matter most for a bank
A bank deploying Dify should settle a small set of platform settings before any app reaches production. These cards cover the secrets, outbound request controls, data stores, identity scopes, app versioning and model provider controls that a model risk, security or audit review will ask about. Confirm each setting against the Dify version you run and your own environment.
Secret key and workspace encryption keys
The SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, so changing it after deployment logs every user out. Decide who generates it, where it is stored and how it is rotated under your key management policy. Workspace encryption keys can be stored locally or in Azure Key Vault, so confirm which option matches your key custody model and who can administer it.
Outbound request filtering with SSRF proxy
Dify workflows and tools can call external URLs, and the SSRF_PROXY settings route those outbound requests through a proxy that blocks internal and private IP ranges. Confirm that the proxy is in the path for every outbound call your apps make, and test that requests to internal addresses are refused. Record the result as evidence for your network security review.
Agent sandbox network isolation
Dify 1.16.1 added agent sandbox network isolation through a Squid proxy, token-based authentication between services and sandboxed Jinja2 template rendering. Agents that run code or reach tools need this isolation to be active and verified in your version. Confirm the behavior in the 1.16.1 release notes and in a test environment before you allow agents to reach production data.
Metadata database and vector store choices
The metadata database can be PostgreSQL (default), MySQL or OceanBase, and the vector store defaults to Weaviate with options such as Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch. These choices set where customer-related records, logs and embeddings reside, so they belong in your data residency map. Confirm backup, restore and high availability support for each choice with your team before selecting it.
Enterprise SSO scopes for workspace and web app access
Dify Enterprise SSO supports OpenID Connect, SAML and OAuth2, with separate scopes for workspace access and web app access. Staff who build apps and customers or employees who only use a web app should not share the same access path. Map each scope to your identity provider groups and confirm the mapping with your access review process.
DSL exports for app versioning
Apps can be exported and imported as YAML DSL files that include workflow nodes, model parameters, prompts and knowledge base connections. Exports exclude third-party API keys, knowledge base content and usage logs, so change records and evidence need a separate retention path. Store exported DSL files in your version control system and confirm this covers approvals and rollback for your model risk process.
Approved model provider list per workspace
Model providers are configured for each workspace, so the list of approved providers can be enforced where apps are built. Record which providers and models your model risk policy allows, and check that no workspace holds credentials for providers outside that list. Confirm the configuration behavior in your Dify version and repeat the check after every upgrade.
How model risk management shapes approved model providers and app versioning
A bank's model risk management function needs to know, for every model that influences a customer or financial decision, what it is, who owns it, who validated it and what changed since. In Dify, that inventory has to be built around the model provider configuration and the app itself. Model provider credentials are set per workspace, so the approved list should name each provider and model the workspace may call, the business owner of each, and the validation record that covers it. Dify does not enforce that list for you. Confirm with your model risk team whether the approval applies to a provider, to a specific model version, or to a model used with particular parameters, and record the answer in the inventory entry. Review who holds rights to add or change provider credentials, because a new provider added in the console changes what every app in that workspace can reach.
Each app is also a model under change control, even when it is built from a visual workflow. A prompt edit, a new workflow node or a changed retrieval setting can alter outputs as much as a retrained model. Treat every such change as a release: the change request should state what changed, the reviewer, the test set used to compare outputs before and after, and the approver who signs off for production. Dify app management lets you export an app as a YAML DSL file, and that file is a useful artifact to attach to the change record. Be aware of what it leaves out. The Dify docs state that exports exclude third-party API keys, knowledge base content and usage logs. Those three items must therefore be tracked separately: credentials in your secrets store with a rotation owner, knowledge base sources with their own data lineage, and logs in your retention system. Otherwise a restored or promoted app will look approved while depending on credentials and data nobody has reviewed.
Two points deserve a decision before go-live. First, decide who may publish a version to production and whether that role is separate from the builder's role. Second, decide how an approved version is identified and recovered if a later change is rejected. Ask your Dify partner or internal team to show how the DSL export for each approved version is stored alongside the model inventory entry and the test evidence, so that an examiner can trace a live app back to the decision that authorized it.
How a bank rolls out Dify from a pilot to a supervised production service
The sequence moves a Dify deployment from a scoped register entry to a production service with documented controls, tested exits and a repeatable upgrade routine. Each phase closes with evidence that a risk, legal or security owner can review before the next phase begins.
Confirm scope and register entry
Risk, procurement and the ICT owner decide which business function the Dify deployment supports and whether it touches a critical or important function. The team records the arrangement in the ICT contractual register and confirms what the DORA Article 28 register must hold for it. Done means a signed scope statement and a register entry that names the hosting location, the data categories and the people accountable for the service.
Classify data and set residency rules
Data owners classify the documents, prompts, conversation logs and knowledge base content the pilot will touch, and decide which classes may leave the bank's own infrastructure. Legal confirms where the contract with any outside provider says services are provided and data is processed. Done means a written classification table and a residency decision that the deployment design must follow.
Build the environment and identity layer
The platform team builds the self-hosted environment in the bank's own accounts or data centers, sets the SECRET_KEY and encryption key handling, and places the metadata database, file storage and vector store where the residency decision requires. Identity is connected through the bank's directory and SSO, with workspace and web app access scoped separately. Done means a restore-tested backup, documented secret storage and a sign-in test for each access group.
Approve model providers and endpoints
Model risk, security and procurement review each model provider and self-hosted endpoint against the bank's approved list, including embedding and rerank models. The team records the contract terms, data handling and the credentials each endpoint uses, then configures only approved endpoints in the workspace. Done means an approval record per model that names the owner, the permitted data classes and the review date.
Run a sandboxed pilot with human review
A small group of users works in a non-production workspace on synthetic or low-risk data, with human review required before any output reaches a customer or a credit, payment or compliance decision. Model risk owners log the test cases, failure modes and reviewer decisions. Done means a pilot report that shows what the model got wrong, how reviewers caught it, and whether the use case stays within its approved boundary.
Test controls and collect evidence
Internal audit or a second-line function tests access control, change tracking, backup restore, outbound request filtering and app versioning against the bank's own control library. Exports of app DSL files are stored with their change records. Teams document where evidence for each control lives, since Dify prepares evidence but an independent assessor forms the opinion. Done means a control test file with pass or fail results and open findings assigned to named owners.
Hand over to production under supervision
The service owner accepts the production service once the pilot report and control tests are signed. Runbooks cover incident escalation, the exit strategy and transition plan for the ICT service, and the monitoring that reviewers use after go-live. Done means a signed handover pack and a named owner for each production workspace.
Run the upgrade routine after each release
Operations reads the release notes for each Dify version, compares the target version's upgrade guide with the bank's configuration, and checks .env.example for new variables before changing anything. A backup is taken before every upgrade, and the change is tested in a non-production workspace first. Done means a change record that links the release notes, the test result and the rollback point.
What banks ask before hiring a partner to deploy Dify
What does a Dify deployment for a bank cost, and what is fixed scope versus retainer?
Cost follows from a written scope, and DeployOpen does not publish a price list. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers, which recur. On the software side, the self-hosted Dify pricing page lists the Community edition as free but limited to a single workspace, and the Enterprise edition as custom priced with SSO, multiple workspaces, advanced security, a commercial license and professional support. Ask for the license cost separately from the implementation fee so you can see what is one-time and what recurs.
What drives the effort of a Dify deployment in a regulated bank?
Effort rises with the number of workspaces, the integrations, the model providers and whether you need Enterprise features. Each workspace needs its own access model, its own data boundary and its own review of apps and knowledge bases. Each integration with a core system, identity provider or document source needs data mapping and testing. Each model provider needs contract, endpoint and credential handling reviewed. Enterprise licensing matters because multiple workspaces and SSO are not available in the Community edition. Ask your partner to list each of these as a separate line in the written scope so you can see which items change the price.
Can our own platform team deploy and run Dify without a partner?
A capable platform team can deploy Dify, and the Community edition runs anywhere Docker runs. The harder part is operating it to a bank's standard: secrets, outbound request filtering, backups, upgrades, access reviews and evidence. The Enterprise resource checklist describes a Kubernetes layout with PostgreSQL 14 or later, Redis 6 or later, a Qdrant vector database and object storage, with a production example of six worker nodes and a three-node Qdrant cluster. Assess your team against that layout, the Docker Compose minimums (at least 2 CPU cores and 4 GB of RAM) and your on-call capacity before deciding which parts to keep in-house.
What does the work need from our identity, network and risk teams?
Identity, network and risk teams each own decisions that the deployment cannot make alone. Identity teams define how users sign in, which groups map to workspaces and which web app access levels apply. Dify Enterprise SSO supports OpenID Connect, SAML and OAuth2, with identity providers such as Microsoft Entra ID and Okta. Network teams decide egress paths to model endpoints and the proxy rules for outbound requests. Risk and compliance teams approve the approved model provider list, data residency, log retention and the model risk documentation for each app. Agree these owners and turnaround times at the start, because they set the schedule more than the build does.
How are upgrades and backups handled for a self-hosted Dify?
Upgrades and backups are planned as recurring work with a tested rollback. The Dify Docker Compose documentation says to follow the upgrade guide for the target version on the GitHub Releases page, to take a backup before every upgrade and to check .env.example for new variables afterward. Minor releases arrive roughly monthly; for example, 1.16.0 was released on July 17, 2026 and 1.17.0 on August 25, 2026. Version jumps can require more than new images, so the upgrade plan should name the target version, the test environment, the backup scope (metadata database, file storage and vector store) and the person who signs off the change.
What evidence does DeployOpen prepare, and what do auditors issue?
DeployOpen prepares systems, controls and evidence for compliance assessments, including configuration records, access designs, backup and upgrade procedures, and testing results. It does not issue audit reports, attestations or certifications. Independent auditors, certification bodies and your supervisor decide whether controls meet a requirement. For DORA, for example, the Regulation sets no certification scheme, and supervisors use their own powers to assess compliance. Ask your partner for a written list of evidence artifacts, the owner of each and how each one is kept current after go-live.
Does DeployOpen offer a guarantee that a bank will pass its review?
No. DeployOpen prepares systems, controls and evidence, but it does not issue audit reports, attestations or certifications, so no outcome of a supervisory or audit review can be promised. What you can ask for is a written scope that names each control, the evidence produced for it, the responsibilities split between your team and the partner, and the retainer terms for keeping that evidence current after go-live.
Compliance evidence a financial team should plan for in a Dify build
A Dify build in a bank or financial firm creates evidence obligations that run from the platform's vendor contract to the prompts that reach production. The four cards below cover the items examiners and assessors most often ask about, and each one names what your team must hold, not just what the software does. DeployOpen prepares systems, controls and evidence for these reviews, but it does not issue audit reports or attestations; independent auditors and certification bodies do.
DORA ICT third-party obligations
If Dify supports a critical or important function, DORA expects the contract to state where the service runs and where data is processed, with advance notice of changes and data return on termination. Article 28(3) also requires the arrangement in your register of information, and Article 28(8) requires a documented, tested exit strategy. Plan the exit as a real migration path: export of apps as DSL files does not carry knowledge base content, third-party API keys or usage logs, so ask how those are returned and rebuilt. Confirm which of these duties apply to your entity type with your regulator and counsel.
Access and MFA evidence
Your records must show who can reach the Dify console, workspaces and API keys, and how each sign-in is authenticated. Under the FTC Safeguards Rule, multi-factor authentication is required for any individual accessing an information system unless the Qualified Individual approves an equivalent control in writing. Dify's community edition is limited to a single workspace, and its SSO features sit in the Enterprise edition, so confirm which identity controls your chosen edition supports before you design the access model. Keep a dated export of role assignments and review them on a set schedule.
Audit logs and change records
Examiners reviewing AI-assisted decisions will ask which prompt, model and knowledge base version produced a given output on a given date. Use Dify's app management and DSL export to keep versioned snapshots of each app, and record who approved each promotion to production. Store these records outside the application database, with retention set by your records policy. Logs of model calls, retrieval and user activity are a separate evidence set, so decide where they are kept, who can read them and how long they are retained.
Where PCI DSS scope could extend
PCI DSS applies to any entity that stores, processes or transmits cardholder data, and to systems that could affect the security of that cardholder data environment. If a Dify workflow receives card numbers, prompts, logs or knowledge base files that contain them, the platform, its database, its vector store, its object storage and its backups may fall inside that scope. The safer design keeps cardholder data out of prompts and documents entirely, and tokenizes or masks it upstream. Confirm the scope with your QSA or assessing body before any payment-related pilot, because the assessment itself is documented by a Report on Compliance or a Self-Assessment Questionnaire with an Attestation of Compliance.
How DeployOpen scopes a financial services Dify engagement
Every financial services Dify engagement starts with a written, fixed scope that names the regulated use cases, the environments, the integrations and the evidence set the work must produce. For a bank or payments firm, the use-case list usually separates internal staff assistants from anything customer-facing, because the two carry different access, logging and model risk expectations. The scope should also fix which Dify components are in play (workflows, knowledge bases, agents, web apps), which model providers sit on the approved list, and which sector systems the platform will call. Before the quote is final, confirm with your own risk and compliance teams which controls they expect to see evidenced, such as app versioning records, audit trails, backup restore tests and the register entries required for ICT services under DORA. Those answers determine the deliverables far more than the software itself does.
Delivery follows the agreed scope in stages, and each stage closes with a written deliverable that your team can review. DeployOpen plans and builds the self-hosted environment inside your own cloud accounts, data centers or air-gapped network, then configures identity, secrets, outbound request controls, storage and backups, and documents how the platform is upgraded. Acceptance is tied to the evidence list in the scope, not to a demo. After go-live, you can choose a retainer for ongoing support, upgrades and continuous security testing, with the retainer scope agreed in writing like the original build. Ask any partner, DeployOpen included, to show which parts of the evidence set are produced by the implementation and which must come from your auditors or assessors, since DeployOpen prepares controls and records but does not issue audit reports or attestations.
How DeployOpen delivers self-hosted Dify for regulated finance
DeployOpen plans, implements, hardens, documents and supports self-hosted Dify inside your own cloud accounts, data centers or air-gapped networks. For banks and financial services, the work is shaped around the evidence your model risk, audit and ICT risk teams will ask for.
How we scope
- Written scope agreed before work starts, covering which Dify apps, knowledge bases and model providers are in and out.
- Mapping of each app to its business owner, data classification and the approved model provider list it may use.
- Decisions recorded on hosting location, metadata database, object storage and vector store, so data residency questions have written answers.
How we build
- Deployment of Dify in your environment with secrets handled through your chosen store and SECRET_KEY set before first use.
- Outbound request filtering through the SSRF proxy settings, sandbox network isolation enabled and access restricted to approved model endpoints.
- Configuration of SSO, workspace roles and app versioning through DSL exports, with change steps tested in a non-production instance first.
How we hand over
- Runbooks for app promotion, change approval, backup and restore, and upgrades that check the release notes and the environment variable reference.
- Evidence pack describing access model, logging, data flows and third-party contracts, prepared for your model risk and audit teams to review.
- Knowledge transfer sessions with your platform, security and application owners, with the open items and their owners written down.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing separately from the initial build.
- Upgrade planning that tests each minor release in staging before production, with backups taken before every change.
- Periodic review of the approved model provider list, access rights and exit plan, with findings tracked to closure in your change process.
