Self-hosted LLM inference for financial services: why the bar is higher
A bank or insurer that wants staff to use language models with client data cannot send that data to a hosted API and hope the contract covers it. The workable answer is a self-hosted inference service on vLLM for shared GPU serving, or Ollama for smaller or local deployments, exposed through an OpenAI-compatible endpoint that stays inside the institution's own network and runs under its ICT risk framework. Applications call that endpoint the same way they would call a hosted API, so the change sits in configuration rather than in every product team's code. Both engines are open source, vLLM under Apache-2.0 and Ollama under MIT, which means the licence is not the obstacle. The obstacle is everything the institution must be able to show about the service once it is running.
The engine is only one component. Under the Digital Operational Resilience Act (*Regulation (EU) 2022/2554*), which has applied since 17 January 2025, an in-house model service is an ICT service that may support critical or important functions, so it needs an entry in the register of information, a contract that states where data is processed, and a documented and tested exit strategy under Articles 28 and 30. Model risk management adds a model inventory entry for each model, with its version, owner, intended use and validation status. Ask your compliance and model risk teams early which inference uses count as models in scope, because that decision determines how much evidence the build must produce.
For the platform itself, a practical starting point is vLLM for shared GPU serving across several departments, Ollama where a single team or a branch needs a small local node, and an AI gateway such as LiteLLM or Apache APISIX in front of both. The gateway handles keys, routing, budgets and request logging, so the engine never faces users directly. Before committing hardware, confirm with your security team that the endpoints the engine exposes are restricted to the ones users need, since the vLLM security documentation recommends a reverse proxy that allowlists only those endpoints. Confirm also that your GPU vendor and driver stack are supported for the engine version you intend to run.
Which financial services requirements shape the build
This table maps the financial services requirements most likely to affect an in-house model service to the design decision each one forces. Read each row as a question to answer before the build starts, with the evidence an assessor or regulator will expect to see. The main takeaway is that most of these obligations land on the contract, the register and the logs as much as on the GPU cluster.
| Requirement | What it asks of the inference service | Evidence to keep |
|---|---|---|
| DORA Article 28(3) register of information | Every ICT arrangement that supports the model service, including the engine's support provider and any hardware or hosting vendor, must be recorded in the register. | Register entries for each vendor, with the services and the functions they support kept current. |
| DORA Article 28(8) exit strategy | If the service supports a critical or important function, a documented and tested exit plan must cover moving models, configuration and workloads to another platform. | Exit plan, transition test results and a tested copy of model artifacts and endpoint configuration. |
| DORA Article 30(2) contract terms | Contracts must state where services are provided and data processed, give advance notice of changes, and cover data return on termination or insolvency. | Signed contract clauses on processing locations, change notice and data return, checked against the actual hosting footprint. |
| PCI DSS v4.0.1 scope | If prompts or outputs can include cardholder data, the inference servers, logs and gateway may fall inside the cardholder data environment and need the matching controls. | Scoping decision with data flow diagrams, and evidence from the assessor or Qualified Security Assessor that the scope boundary was confirmed. |
| Swift CSP controls | Where the model service is linked to payment messaging or connected payment systems, the Swift Customer Security Controls Framework applies to that environment. | Mapping of mandatory and advisory controls to the inference hosts, the access paths and the admin tooling, plus the annual independent assessment result. |
| FTC Safeguards Rule MFA (16 CFR 314.4(c)(5)) | Non-bank lenders must require multi-factor authentication for anyone accessing the inference service, its admin consoles and the systems that hold its data, unless the Qualified Individual approves an equivalent control in writing. | Written MFA policy, enforcement settings on the gateway and admin paths, and any signed equivalent-control approval. |
| SEC Release 33-8810 IT general controls | For listed or SOX-scoped firms, change management, access and computer operations for the service support internal control over financial reporting if its outputs feed reported figures. | Change records for model and engine upgrades, access reviews, job and backup logs, and a list of systems in scope for the assessment. |
| EU AI Act Articles 12 and 19 logging | If the use case is classed as high-risk, the system must technically allow automatic event logs over its lifetime, and providers keep them for at least six months unless other law requires longer. | Log design that captures requests and model versions, retention settings of at least six months, and a documented owner for log access. |
Which data and systems an inference service touches in a bank
The first decision for a bank or insurer is to map what a prompt actually carries. In practice, prompts and retrieved documents include customer records pulled from core banking or policy administration systems, claims files with medical or injury details, credit memos with income and exposure figures, and trading or underwriting notes. The flow usually runs from an employee tool such as a chat interface or an internal application, through an AI gateway that handles keys, budgets and routing, to the inference engine, and then into logs, traces and metrics stores. Each hop is a place where regulated data can be copied, so the data inventory should list every hop, its owner and its retention period, not only the model server.
Ollama states that when it runs locally it does not see your prompts or data, and that cloud features can be turned off with OLLAMA_NO_CLOUD=1 or the server configuration file. That statement covers the engine itself. It does not cover the rest of the stack. The institution must verify its own configuration: the gateway's request logging, the observability platform's trace capture, reverse proxy access logs, and any crash or telemetry reporting in the container images. Confirm with each vendor which fields are written to disk and where, and test a sample request end to end by searching the log stores for a known test string. Treat the logging configuration as part of the data scope, not as a vendor assurance.
The same mapping feeds the record-keeping questions. Where a system is high-risk under the EU AI Act, Article 12(1) requires automatic event logging over the system's lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. Banks should decide early which logs are compliance evidence, which are debugging data that must be minimized, and who may access each set. Those decisions determine how long prompt content can be kept, whether it can be redacted, and which ICT contracts must cover the storage locations, which DORA Article 30(2) requires contracts to state.
Which open-source platforms fit a regulated inference stack
A regulated inference stack usually combines a serving engine, a gateway that controls access and spend, an observability layer and a chat front end. Each component below has a different license, network exposure and evidence role, so the choice should follow from what the bank must control and record.
vLLM for shared multi-GPU serving
vLLM is the engine most likely to carry shared production traffic across several GPUs. It is licensed under Apache-2.0, and its server started with vllm serve exposes OpenAI-compatible endpoints, so existing applications can point at it. Check the security documentation before exposure: the --api-key option does not cover every endpoint, and the project recommends a reverse proxy that allowlists only the routes users need. Multi-node traffic is insecure by default and must sit on an isolated network.
Ollama for smaller isolated nodes
Ollama suits single machines, branch servers or isolated enclaves where a full serving cluster is not justified. It is MIT licensed and binds to 127.0.0.1 on port 11434 by default, with no authentication on the local API. Teams that expose it to other services must place a proxy in front and set the bind address deliberately. Confirm that cloud features are disabled with OLLAMA_NO_CLOUD=1 so no inference leaves the network.
LiteLLM as the access and logging gateway
LiteLLM sits between applications and model endpoints to issue keys, enforce budgets per team, route requests and record usage. It is MIT licensed except for its enterprise directory, so confirm which features the bank needs fall outside that carve-out before committing. The gateway is where access decisions and request logs become auditable records, so its own administrative access and log storage belong in the scope of the bank's access reviews.
Langfuse for traces kept in-house
Langfuse records prompts, outputs, latency and cost for LLM applications, which supports model monitoring and incident reconstruction. It is MIT licensed except its ee directories, and its copyright holder is ClickHouse, Inc. The storage behind it holds customer-derived text, so the bank should set retention periods, restrict access to traces and confirm that the database and backups stay inside its own environment.
Open WebUI and LibreChat for staff chat
Open WebUI and LibreChat give staff a ChatGPT-style interface on top of the internal endpoint. LibreChat is MIT licensed. Open WebUI carries a license clause that prohibits altering or removing its branding, with exceptions that include deployments of no more than 50 end users in any rolling 30 day period, so a bank with more users needs written permission or another listed exception before changing its look. Confirm the choice against the bank's user count and identity integration.
Arize Phoenix only for internal use
Phoenix provides LLM tracing and evaluation under the Elastic License 2.0, which prohibits providing the software to third parties as a hosted or managed service. A bank that runs Phoenix for its own teams inside its own environment is in a different position from a vendor that operates it for clients. If a managed partner will operate the observability layer for the bank, legal review of the license terms is required first.
Deployment patterns for banks, insurers and their GPU estates
Each pattern below answers a question an institution must settle before a model service goes live: where the GPUs sit, how the engine is deployed, how nodes talk to each other, how production is separated from testing, how the service recovers, and where data may physically live. The patterns combine, so a bank will usually pick one hosting model and then layer the others on top of it.
Dedicated inference zone on private GPU hosts
Place GPU hosts in a segment of their own, with inbound traffic allowed only from the gateway or application tier that calls the model. Engine endpoints such as vLLM's API server should never sit directly on a general user network. The vLLM security documentation recommends a reverse proxy that allowlists only the routes meant for users, because the --api-key option does not cover every route, including /metrics and /health. Check who can reach administrative routes, who administers the hosts, and whether the zone falls inside the scope of your change and access controls.
Kubernetes deployment with supported options
The vLLM Kubernetes documentation lists native manifests, Helm, the vLLM production-stack, AIBrix, KServe, KubeRay, LeaderWorkerSet, llm-d and NVIDIA Dynamo. Each option brings different components to maintain, different upgrade paths and different owners for the cluster. A bank should pick one option, pin its versions and record it in the configuration baseline. Ask the partner which option it will support for the full contract period, how GPU scheduling is isolated between tenants, and how the cluster itself is patched and backed up.
Multi-node serving on an isolated network
Large models often span several nodes, with tensor parallelism inside a node and pipeline parallelism across nodes. The vLLM security documentation states that communication between nodes is insecure by default, with no authorization or encryption, so the node-to-node network must be isolated and accessible only to cluster members. Confirm the network design with the network team, document which ports and protocols carry model traffic, and test that nodes outside the cluster cannot reach them. Where a single node can hold the model, this risk is avoided entirely.
Separate production and non-production pools
Run development, testing and model evaluation on GPU pools that are physically or logically separate from production inference. Test pools can take new engine releases and model candidates before they reach customers. Engine releases arrive frequently, with vLLM shipping minor releases about every two weeks in the period from August to October 2026, so a test pool that tracks the release cadence gives the change board evidence before each promotion. Keep production data out of test pools unless the data owner has approved it, and document the promotion path from one pool to the other.
Disaster recovery for artifacts and configuration
Recovery depends on having the model weights, container images, engine configuration, gateway routes and access policies available at a second site. Store model artifacts and configuration in a repository that is backed up and checksummed, and rehearse a restore on the recovery site. The recovery plan should state the recovery time and recovery point the business has accepted, and which team can switch traffic. For DORA-regulated entities, the same artifacts also support the exit and transition plan for the service, so keep them documented and tested together.
Air-gapped or EU-hosted variants
Some institutions must run inference with no connection to the internet, while others must keep processing inside EU facilities. An air-gapped design needs weights, images and updates moved across the boundary under a documented verification step. An EU-hosted design needs a named facility, operator and location for the GPU hosts, with the location written into the contract, as DORA Article 30(2) requires for data processing locations. Confirm which of these your data location rules require before choosing a pattern, because a hosted option inside a cloud region may not meet the same test as hardware in your own data center.
How a bank rolls out an in-house inference service in phases
The sequence moves from a DORA-mapped use-case inventory to a controlled pilot, with each phase closing on a written artifact that a risk function, auditor or supervisor can review. Nothing reaches pilot users until the exit plan has been tested against a second model or provider.
Scope use cases and map them to DORA functions
The bank's business owners, risk function and IT architects list every proposed use of the model service, from internal drafting to customer-facing tools. Each use is classified by whether it supports a critical or important function under DORA, which determines how far the ICT risk, register of information and exit requirements apply. The step closes when the inventory names an owner, a data classification and a criticality decision for each use, and the register of information entry for the service is drafted.
Select models and hardware with a model inventory entry
The model risk team and platform engineers agree on candidate open-weight models, context lengths, accelerator types and the engine, such as vLLM or Ollama, against the use-case requirements. Each candidate gets a written model inventory entry covering version, license, intended use, known limitations and the validation owner. The step closes when the inventory entry is approved and the hardware order or allocation is tied to a documented sizing basis.
Build an isolated environment and harden the endpoint
Platform engineers deploy the inference servers in a segmented network zone, with the engine bound to internal addresses only and a reverse proxy in front that exposes just the endpoints users need. Authentication, network controls and multi-node traffic protection are configured, because the engine's own API key does not cover every route. The step closes when a security team test confirms that unlisted routes, metrics and administrative endpoints are unreachable from user networks.
Configure evidence and logging for Articles 12 and 19
The team decides, with legal and compliance, whether the use cases fall within the EU AI Act's high-risk scope, and if so configures automatic event logging and retention to meet Article 12(1) and the six-month minimum in Article 19(1). Logs, access records, model versions and configuration history are stored in the bank's own systems with defined retention and access controls. The step closes when a sample set of events can be retrieved, reviewed and linked to a model version and requesting system.
Test load and peak capacity
Performance engineers run load tests that mirror the expected concurrency, prompt sizes and peak periods, measuring latency, queueing and throughput, and check the engine's metrics output against those results. Failure modes such as GPU memory exhaustion, queue overflow and node loss are rehearsed with documented responses. The step closes when the results are signed off against agreed service targets and the capacity thresholds that trigger scaling or request limits are written down.
Prove the exit and transition plan against a second model
Before any user relies on the service, the team exports the model artifacts, configuration and integration contracts, then rebuilds the service with a second model or an alternative provider to confirm the application layer can switch without rewrites. Data return and contract terms are checked against the requirements in DORA Article 30(2). The step closes when the rehearsal produces a dated test record, the exit plan has named owners, and any gaps are logged as remediation items.
Release to pilot users under controlled access
The service is opened to a named pilot group with access managed through the bank's identity controls, usage monitoring turned on and a rollback path that has been tested. Feedback, incidents and output quality issues are reviewed against the model inventory entry, and access widens only when the risk owner approves. The step closes when the pilot review records approved scope, open findings and the decision to expand, hold or withdraw.
Evidence auditors and supervisors ask for, and what produces it
This table maps each piece of evidence that examiners, auditors and supervisors commonly request for an in-house model service to the system that produces it and where it tends to be missing. Read it as a preparation list: the right-hand column names what to confirm with your assessors before collection starts. DeployOpen prepares this evidence, but independent auditors, supervisors and certification bodies issue any assessment, attestation or opinion.
| Evidence | What it shows | What produces it | Where it usually goes missing |
|---|---|---|---|
| Model inventory entry | Which open-weight model, version, license, owner, intended use and risk tier are in production | Model register kept in the model risk management system, linked to the serving configuration and weight checksums | Weights swapped or quantized without a new inventory version |
| DORA register of information entry | The inference platform as an ICT service, its provider, location and supporting function | Entry in the third-party ICT register under Article 28(3), updated for each in-house component and vendor | Open-source components treated as having no provider, so no entry is made |
| Contract clauses on data location and return | Where prompts, logs and model artifacts are processed and how data comes back on termination or insolvency | Contracts with implementation partners and any hosting provider covering Article 30(2) points | Partner agreements silent on data return or on where support staff access systems |
| Exit plan and test record | A documented, tested route to move the service to another platform or back in-house | Exit strategy under Article 28(8), with a dated record of a restore or transition test | Plan written but never tested, or model weights not stored in a second location |
| Change records for engine and model upgrades | Who approved each vLLM, Ollama or model change, what was tested and when it went live | Change tickets linked to release notes, regression test results and rollback steps | Frequent engine releases applied directly to production with no record |
| Access reviews on gateway keys and endpoints | Which teams and services hold API keys, and whether access was reviewed and removed when no longer needed | Periodic exports from the gateway or reverse proxy, signed off by the service owner | Shared keys, and the engine's own endpoints reachable without a proxy allowlist |
| MFA evidence for administrative access | That every person reaching the GPU hosts, admin consoles and key management has multi-factor authentication, or an approved equivalent | Identity provider logs and configuration exports for administrative paths | Break-glass accounts and SSH access to inference nodes outside the identity provider |
| Prometheus metrics retained for capacity review | Request volume, token throughput, latency and KV cache use over time, supporting capacity decisions for peak periods | Metrics from the vLLM /metrics endpoint scraped and stored with a retention period set by policy | Short default retention, so month-end or quarter-end peaks are lost before review |
| Traces from Langfuse | Which prompts, model calls and outputs were processed, supporting incident reconstruction and model monitoring | Self-hosted Langfuse storing traces under the organization's own retention and access rules | Tracing disabled for performance reasons, or prompt content stored without access controls |
| Penetration test results | That the endpoints, gateway and inference nodes were tested and that findings were tracked to closure | Scoped test reports with retest evidence, covering the API, the reverse proxy and the GPU hosts | Tests that exclude the engine's unauthenticated paths or the internal node network |
What do banks ask before running their own LLM inference?
What does running your own LLM inference cost, and what drives it?
The cost has four main parts: accelerator hardware or rental, power, space and cooling, and the people who operate and test the service. The engine itself, vLLM, is Apache-2.0 licensed with no paid edition, so the spend sits in GPUs, the surrounding infrastructure, implementation and staff time. Utilization is the largest driver: idle GPUs still cost money, while a service sized for peak periods without a plan for queueing will waste capacity or fail under load. Recurring costs include on-call time, engine upgrades, evidence collection and periodic testing. Ask any partner for a quote that separates one-time work (design, build, hardening, documentation) from recurring work (operations, upgrades, testing) and states which GPUs and power assumptions it uses.
How long does a self-hosted inference platform take to deliver for a bank?
The timeline depends on the agreed scope, the hardware lead time and the approvals your bank needs before production. Model risk, information security, vendor risk and change management reviews often run in parallel with technical work, and they are frequently the longest path. DeployOpen does not publish durations. Most engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. Confirm in that written scope which approval gates are included, who signs each one, and what your bank must provide, such as network access, identity integration and a named business owner.
Can our internal team run an LLM inference service without a partner?
Some banks can, particularly where platform engineering already operates GPU clusters and container platforms. The harder part is not the engine but the duties around it. DORA expects a register of information on ICT contractual arrangements, tested exit strategies for ICT services that support critical or important functions, and contracts that state where data is processed. Each of these needs a named owner, a documented process and evidence. Before deciding, check whether your team can provide those owners, run capacity planning and handle engine releases, which for vLLM arrived roughly every two weeks in 2026. A partner can build and document the platform, but accountability for the duties stays with your bank.
Is a hosted API simpler, and what do we give up by choosing one?
A hosted API is usually simpler to start, because the provider runs the hardware and the model. The trade-off is where your data is processed and how you can leave. Under DORA Article 30(2), your contract must state the locations of service provision and data processing and must cover data return on termination or insolvency. Compare the provider's processing locations, subprocessors, change notice, logging and exit terms against your own requirements, and compare them with the cost of GPUs, staff and testing. Many banks use a hybrid approach, keeping client-data workloads on self-hosted models while using hosted services for public or non-sensitive content. Confirm each option with your legal, third-party risk and information security teams.
Which inference engine should a bank choose?
Choose based on the models, concurrency and hardware you need. vLLM, an Apache-2.0 engine, is built for GPU serving with an OpenAI-compatible API, tensor and pipeline parallelism across GPUs and nodes, and Prometheus metrics. Ollama, MIT licensed and built on llama.cpp, suits smaller deployments and CPU or workstation use, and its default concurrency settings (one parallel request per model by default) need tuning before serving many users. llama.cpp suits constrained edge hardware. Test each candidate against your latency targets, the context lengths your use cases need and your upgrade cadence. Confirm current versions and supported hardware with the project before you commit.
What should we do about the vLLM endpoints the engine leaves open?
Do not expose the vLLM server directly to users or applications. The vLLM security documentation states that the --api-key option protects the /v1, /v2, /inference and /cohere paths but not endpoints such as /metrics, /health, /pause, /resume, /abort_requests or /invocations, and it warns against relying on the key alone. The documented approach is a reverse proxy that allowlists only the endpoints meant for users, with authentication, TLS and logging at the proxy. Also restrict /metrics to your monitoring network, and isolate multi-node traffic, because the docs describe inter-node communication as insecure by default. Include these controls in your penetration test scope and your access-control evidence.
Questions to ask an implementation partner before signing
Start with capacity, because it decides the hardware and the contract. Ask the partner to show how they size GPUs for your peak period, not the average load: which month-end, trading or claims surge they modeled, what concurrency and context length they assumed, and how they tested it against the model and quantization you plan to run. Ask whether the sizing includes a second node for failover, how tensor parallelism is set within a node, and whether multi-node traffic will cross a network they have verified as isolated, because the vLLM security documentation states that node-to-node communication is insecure by default. Ask for the sizing worksheet in writing, so the assumptions can be checked against your own transaction calendar.
Next, test how they close the endpoints the engine leaves open. Ask them to name every route exposed by the vLLM server that the --api-key option does not protect, including /metrics, /health and /invocations, and to show the reverse proxy allowlist that exposes only the routes staff and applications use. Ask how they handle engine releases, which arrive about every two weeks, and whether each upgrade is re-tested against that allowlist, the model weights and your logging before it reaches production. Ask who approves a release, how long a rollback takes and what change record the institution receives, since your DORA ICT change process and model risk function will want that trail.
Finally, ask what evidence and handover they will produce for your regulators. For DORA, ask for the contract terms that name where the service runs and where data is processed (Article 30(2)), the input to your register of information (Article 28(3)), and a documented, tested exit and transition plan (Article 28(8)). For model risk management, ask for the model inventory entries, version records and access logs, and confirm with your second line and supervisor which retention periods apply. Ask who holds the administrator keys, the encryption keys and the log archive, whether you can revoke the partner's access without their help, and how operations pass to your team through runbooks, on-call training and a tested recovery exercise. Answers that are generic across regulators should prompt a follow-up.
How DeployOpen scopes and supports a bank's inference platform
The sequence moves from a written scope to a platform that runs inside the bank's own infrastructure, with evidence prepared for assessors and ongoing support that the bank can act on. Each step ends with an output the bank can check.
Agree the scope and model inventory in writing
DeployOpen works with the bank's architecture, security, model risk and procurement teams to define the models, user groups, peak-period expectations, endpoints and out-of-scope items. The output is a written scope with deliverables and a timeline agreed before work starts, plus an initial model inventory entry for each model and its license. The step is closed when the bank's named owners have signed off the document.
Map ICT dependencies and contract terms
DeployOpen documents every component the platform depends on, including the inference engine, gateway, vector store, container images, model weights and any third-party hardware plugins, and records where each is hosted and which party operates it. The bank uses this map to populate its register of information and to check that any contractual arrangements state where services run and how data is returned. The step closes when the bank's third-party risk team has reviewed the dependency map.
Design the network, identity and endpoint controls
DeployOpen designs the GPU network segment, the reverse proxy that allowlists only the endpoints meant for users, authentication in front of the engine, and separation of multi-node traffic on an isolated network. Because the vLLM security documentation states that inter-node communication is insecure by default, this design is a required input rather than an afterthought. The output is an architecture document and access model that the bank's security team approves before deployment.
Implement and harden the inference stack
DeployOpen installs the chosen engine, such as vLLM or Ollama, the gateway and the observability components inside the bank's accounts or data centers, and applies hardening baselines, configuration management and secrets handling. Exposure of management endpoints and metrics paths is tested against the design. The step closes when a test run confirms that only intended endpoints answer from the user network and that no component reaches outside the approved boundary.
Build logging, monitoring and capacity views
DeployOpen connects engine metrics, such as request counts, token throughput, latency and KV cache use, to the bank's monitoring stack and sets alerts and capacity dashboards for peak periods. Audit logs for prompts, access and configuration changes are routed to storage with a retention period the bank sets. The output is a monitoring runbook and sample dashboards, and the step closes when the bank's operations team can see load and failures in one place.
Test security, including AI-specific checks
DeployOpen runs configuration and access testing against the endpoints, and, if the bank chooses, a security testing engagement covering AI systems that probes prompt handling, data exposure and abuse of the endpoints. Findings are logged with owners and fixed before handover. The output is a test report and a remediation record, and the step closes when the bank accepts the residual risks in writing. Testing is an optional add-on priced in the same written scope.
Prepare evidence for assessments
DeployOpen assembles the evidence the bank's internal audit, regulators and external assessors are likely to request, such as architecture records, configuration baselines, access reviews, change records, backup and restore results and the exit plan documentation. DeployOpen prepares and organizes this material but does not issue any audit report, attestation or certification, which remains the role of the bank's assessors. The step closes with an evidence index the bank can hand to its assessors.
Hand over operations and support the platform
DeployOpen delivers operating documentation, runs knowledge transfer with the bank's platform team and tests backup, restore and failover procedures. After handover, ongoing support, engine upgrades and continuous testing can be covered by a retainer scoped in writing. The output is a signed handover record and an agreed support schedule, and the step closes when the bank's team has performed a restore and an upgrade without DeployOpen operating the system alone.
