Vendor governance responsibility model
DALP separates platform controls from the third-party services, operating procedures, and regulatory evidence that a financial institution owns when it assesses outsourcing, DORA, and vendor governance obligations.
DALP gives regulated operators product evidence for tokenization controls, deployment topology, auditability, and operating handoffs. It does not replace the financial institution's outsourcing governance, DORA classification, vendor due diligence, regulatory notification, or incident-reporting process. Those obligations depend on the selected deployment model, providers, contracts, and the institution's own risk policy.
This page is an explanation for architecture, security, and procurement reviewers. It maps what DALP can evidence, what an external provider owns, and what the operator must govern outside the platform.
Responsibility model
A vendor governance review should separate DALP product behaviour from the services that operate or support it. The same DALP deployment can have different governance evidence depending on whether SettleMint operates the environment, the customer hosts it, or a third party operates selected infrastructure.
| Review area | DALP evidence | Operator or provider evidence |
|---|---|---|
| Deployment ownership | Deployment topology, self-hosting model, managed services split, and handover responsibilities | Outsourcing classification, contract owner, service owner, and exit plan |
| Access and identity | Authentication, authorization, wallet verification, API-key handling, role checks, and audit surfaces | Identity-provider policy, staff joiner-mover-leaver process, endpoint security, and access-review cadence |
| Transaction control | SMART Protocol roles, identity and compliance checks, signer or custody routing, and indexed transaction evidence | Custody-provider policy, approval quorum, key ceremony, signer availability, and provider audit material |
| Availability and recovery | High-availability patterns, backup and recovery planning, recovery evidence, and RTO/RPO dependency mapping | Contracted service levels, restore drill results, provider resilience evidence, and board or regulator reporting |
| Chain and infrastructure providers | Chain Gateway, Chain Indexer, EVM network configuration, and source-verification evidence | RPC or node provider resilience, bridge provider evidence when used, cloud provider evidence, and network-operator risk review |
| Incident evidence | Logs, traces, request identifiers, workflow state, transaction hashes, indexed events, and deployment evidence | Formal incident classification, regulatory notification, customer communications, legal assessment, and third-party notification obligations |
What DALP can support in a review
DALP supports vendor and operational-resilience reviews by making the platform architecture and operating evidence inspectable:
- Architecture evidence: deployment topology, service ownership, managed-service choices, and the split between application runtime, data plane, signer or custody path, and EVM network access.
- Security evidence: authentication, authorization, wallet verification, signer routing, SMART Protocol roles, compliance modules, and the point where an EVM transaction changes asset state.
- Audit evidence: deployed addresses, source-verification material where available, transaction hashes, indexed events, request identifiers, error records, and reporting or audit access.
- Recovery evidence: backup and restore planning, high-availability patterns, recovery ownership, and the service dependencies that influence RTO and RPO targets.
- Integration evidence: custody providers, compliance providers, RPC or node access, observability, object storage, and other external services selected for the environment.
These are product and deployment facts. They help an institution assemble its evidence pack, but they do not turn DALP into the institution's outsourcing governance programme.
What remains operator-owned
The operator owns the decisions that sit outside DALP product behaviour:
| Decision | Why DALP does not decide it |
|---|---|
| Whether the deployment is a critical or important ICT service | The classification depends on the institution's regulated activity, risk appetite, dependency model, and supervisory interpretation. |
| Which providers are approved | Provider selection depends on procurement, legal terms, data residency, concentration risk, audit rights, and local policy. |
| Which incidents must be reported | Formal incident reporting depends on legal thresholds, affected services, customer impact, timing, and jurisdiction. |
| Which RTO and RPO targets are promised externally | Targets depend on the selected availability pattern, provider contracts, capacity, backup design, and restore drill results. |
| Which evidence can be shared with a regulator or customer | Evidence release depends on commercial terms, confidentiality, audit scope, and the institution's disclosure process. |
| Which exit or substitution plan applies | Exit planning depends on the hosting model, data export process, provider contracts, custody setup, and operational runbooks. |
DALP documentation should be used as product evidence inside that review, not as a substitute for the review.
Evidence pack checklist
For a DORA, outsourcing, or third-party risk review, collect the following evidence before making external commitments:
- Deployment model: managed service, customer-hosted, or hybrid operating split, including the party operating Kubernetes, PostgreSQL, object storage, observability, and backup storage.
- Runtime services: ingress, Asset Console, Unified API, workers, Chain Gateway, Chain Indexer, feeds, and any addon workspaces used by the deployment.
- Data and recovery: backup scope, restore cadence, retention policy, restore test evidence, and measured recovery results for the actual environment.
- Identity and access: identity-provider configuration, API-key governance, administrator roles, wallet verification settings, and access-review cadence.
- Signing and custody: signer or custody provider, approval policy, key ceremony evidence, provider availability, and escalation path.
- Provider chain: cloud, custody, compliance, RPC or node, observability, storage, and any bridge or cross-chain service used by the deployment.
- Audit trail: request identifiers, workflow state, transaction hashes, indexed events, deployed addresses, source-verification material, and audit or license evidence available for the deployed scope.
- Incident process: internal severity model, legal or regulatory notification route, provider notification contacts, communication owner, and evidence retention path.
How to use DALP docs in the review
Start with the deployment and security pages, then add provider evidence for the selected environment:
- Deployment topology explains the operating model, service responsibilities, RTO/RPO dependencies, and failure-domain examples.
- High availability explains availability patterns without turning them into a universal SLA.
- Backup and recovery explains restore planning and recovery evidence.
- Security overview maps authentication, authorization, wallet verification, compliance checks, custody policy, and on-chain enforcement.
- Source verification and deployment auditability explains source, bytecode, address, audit, and dependency evidence.
- Operational integration patterns explains integration ownership across deployment, custody, observability, and provider services.
Keep the answer specific to the deployed environment. A generic product statement cannot prove the resilience, evidence, provider approval, or incident process for a production deployment.
Smart contract source verification and deployment auditability
How DALP makes deployed EVM contract systems reviewable through recorded deployment addresses, bytecode checks, migration verification, timelock boundaries, formal-assurance boundaries, upgrade evidence, and operational audit trails.
Public chain privacy on EVM networks
How DALP separates public EVM chain records from off-chain identity and compliance evidence. Covers public visibility, mempool and MEV exposure, transaction ordering, and operator-owned privacy controls.