DORA / ICT Outsourcing Addendum

This DORA / ICT Outsourcing Addendum (the "Addendum") is offered by 403 Finance, Inc., a Delaware corporation with offices at 1111B S Governors Ave, Ste 92573, Dover, DE 19904, USA ("403 Finance," "we," "us," or "our"), to a Customer that is a "financial entity" within the meaning of Regulation (EU) 2022/2554 (the Digital Operational Resilience Act, "DORA") and that uses Transmute (the "Service"). Capitalized terms used but not defined in this Addendum — including Service, Message Content, Output, Usage Metadata, Customer, API Credentials, and DPA — have the meanings given to them in our Terms of Service (the "Terms"). Its purpose is to enable a Customer that is a financial entity to satisfy the contractual requirements of Articles 28 and 30 of DORA in respect of the Service without imposing its own paper on us. 403 Finance is an ICT third-party service provider for the purposes of DORA; nothing in this Addendum makes 403 Finance a "critical ICT third-party service provider" designated under Article 31 of DORA.

1. Purpose and Application

(a) When this Addendum applies. This Addendum applies where the Customer is a financial entity subject to DORA (or to analogous outsourcing or ICT third-party risk-management requirements under the EBA, EIOPA, or ESMA guidelines) and has executed this Addendum or accepted it in the course of subscribing to the Service. Where the Customer is not such a financial entity, this Addendum does not apply and the Terms alone govern.

(b) Relationship to the other agreements. This Addendum supplements, and forms part of, the Terms or, where the parties have entered into a Master Services Agreement (the "MSA"), that MSA, together in each case with the DPA. It does not replace them. For the specific matters this Addendum covers — namely the contractual provisions required by Articles 28 and 30 of DORA — this Addendum prevails over the Terms, the MSA, and the Acceptable Use Policy (the "AUP") to the extent of any conflict. The DPA continues to control for data-protection matters, as set out in Section 10.

(c) Customer's own assessment and register. The Customer is responsible for its own assessment of whether the Service supports a "critical or important function" of the Customer within the meaning of DORA, for the resulting classification of the ICT services described here, and for its own register-of-information entries under Article 28(3) of DORA. 403 Finance provides the information in this Addendum, and in the documents it references, to enable the Customer to make that assessment and to complete those entries. We do not make that assessment on the Customer's behalf.

2. Service Description and Locations

(DORA Article 30(2)(a) and (b))

(a) Description of the ICT services. The Service is a hosted, usage-metered application programming interface that converts, normalizes, and validates financial messages between SWIFT MT and ISO 20022 formats. It receives Message Content that the Customer submits, processes it, and returns Output to the Customer. The Service does not connect to the SWIFT network or any payment network or scheme, does not hold, settle, or transmit funds, and does not screen Message Content for sanctions, anti-money-laundering, or other regulatory purposes; those functions and the onward use of Output remain the Customer's responsibility, as set out in the Terms.

(b) Locations of data processing and storage. The Service processes and stores data in the European Union. Compute and edge termination run on Cloudflare Workers and Containers in the WEUR (Frankfurt) region; Usage Metadata and encrypted batch ciphertext are stored in Neon Postgres on Amazon Web Services in the eu-central-1 (Frankfurt) region. EU-only processing of Message Content is a product commitment. The Service does not rely on any other geographic region for the provision of the Service.

(c) Administrative access locations. Day-to-day administration, support, and incident response are performed from the United Kingdom; for EU personal data, that access is covered by the European Commission's adequacy decision for the United Kingdom. 403 Finance is a Delaware (United States) corporation, and any residual access from the United States is a restricted international transfer safeguarded by the EU Standard Contractual Clauses and the related transfer mechanisms incorporated into the DPA. We do not represent that data never leaves the European Union; we disclose these access locations and safeguard the associated transfers.

(d) Notice of location changes. We will give the Customer advance notice before we materially change the geographic locations in which the Service processes or stores data, so that the Customer can conduct any assessment its regulatory obligations require. A change in the location of a sub-contractor is additionally handled through the sub-processor notification mechanism in Section 8.

3. Data Protection and Security

(DORA Article 30(2)(c) and (d))

(a) Accessibility, integrity, and confidentiality. 403 Finance commits to ensuring the availability, authenticity, integrity, and confidentiality of data in connection with the Service in accordance with the DPA and the technical and organizational measures set out in Annex II of the DPA. Those measures — which include encryption in transit (a minimum of TLS 1.2, edge-to-origin) and encryption at rest (AES-256-GCM), passwordless authentication, hashing of credentials and session tokens, tenant isolation, least-privilege administrative access, and body-free logging, metrics, and tracing — are the binding security obligations for the Service. The Security Overview is an informational description of them and is not a contract term.

(b) Statelessness architecture. Message bodies are never persisted and never logged; Postgres stores metadata only (type, size, duration, status, warning counts). There are exactly two sanctioned exceptions:

• (i) Idempotency response cache. So that a safely retried request does not double-process, the Service caches a response keyed by a hash of the request body — the raw body is never stored. Entries carry a 24-hour maximum time-to-live and expire unconditionally. In production this cache runs on an encrypted volume.
• (ii) Encrypted batch job store. Asynchronous batch jobs store inputs and results only as AES-256-GCM ciphertext. Batch inputs are purged at the completion of each item; results default to a one-hour retention and are configurable by the Customer from one minute up to a 24-hour maximum; a sweeper enforces expiry on a fixed cadence; and the Customer can purge on demand via DELETE /v1/jobs/{id}.

(c) Bounded blast radius. Because 403 Finance holds no archive of Message Content or Output, the scope of any worst-case event is bounded by construction: it is limited at most to the batch jobs in flight or within their retention window and the idempotency-cache entries within their window, plus metadata and credential hashes. There is no historical payload data to expose, because none is kept.

(d) Recoverability and exportability. Data connected with the Service is recoverable and exportable by the Customer as described in the Exit and Termination Assistance Statement and in Section 9. Because the Service is stateless, the Customer's Message Content and Output are, by design, retained by the Customer rather than by us, and there is no accumulated store of the Customer's message data held at 403 Finance to migrate on exit.

4. Incident Reporting

(DORA Article 30(2)(f))

(a) Notice of ICT incidents. We will notify the Customer without undue delay of any ICT-related incident that affects the Service provided to the Customer, and of any significant cyber threat affecting that Service of which we become aware. Our notice will include the information reasonably available to us that the Customer needs to perform its own DORA incident-classification and reporting duties — including the nature of the incident, the systems and functions affected, the time of detection, our assessment of impact on the Service, and the remedial and containment steps taken or planned — and we will supplement it as further information becomes available.

(b) Cooperation with the Customer's obligations. We will cooperate, on a commercially reasonable basis, with the Customer's own major-ICT-incident classification, notification, and reporting obligations to its competent authorities under Articles 17 to 23 of DORA, including by providing information reasonably necessary for the Customer's initial, intermediate, and final reports.

(c) Security incidents prioritized. Suspected security breaches and credential compromise are prioritized ahead of the tiered support targets for all customers, regardless of Plan or support tier, consistent with the Support and Availability Policy (the "Support Policy"). The Customer should report a suspected security incident to security@403fin.io.

(d) Notification timing. Data-breach notification timing is governed by the DPA.

5. Service Levels and Reporting

(DORA Article 30(2)(e))

(a) Availability and support targets. The service-level descriptions for the Service — including the 99.9% monthly availability target and the tiered first-response targets — are set out in the Support Policy. As stated there, those figures are operational targets, not warranties, service-level agreements, or guarantees, and no service credits arise on self-serve Plans. A credit-bearing service-level agreement is available only under a separately negotiated Enterprise agreement.

(b) Periodic service reports. On the Customer's reasonable request, and at a reasonable cadence, we will provide the Customer with periodic reports covering the availability of the Service and any ICT incidents that affected the Service provided to the Customer during the reporting period, to support the Customer's ongoing monitoring of the ICT services under Article 28(1) of DORA.

(c) Monitoring. The Customer remains responsible for its own ongoing monitoring of the performance of the ICT services and for the exercise of its rights under this Addendum; nothing in this Section transfers that responsibility to us.

6. Training and Cooperation

(DORA Article 30(2)(i))

(a) Participation in awareness and testing. Where reasonably relevant to the Service and on reasonable prior notice, we will participate in the Customer's ICT security awareness programs and digital operational resilience testing to the extent those activities relate to the Service we provide, including by responding to reasonable requests for information and providing a knowledgeable point of contact. Any such participation is at the Customer's reasonable cost and is scheduled so as not to disrupt the Service. This Section does not require us to participate in threat-led penetration testing of shared infrastructure in a manner that would affect other customers; access for testing is instead governed by Section 7.

7. Audit, Access, and Information Rights

(DORA Article 30(2)(g) and 30(3)(e))

(a) Grant of access and audit rights. We grant the Customer, its statutory auditors and appointed representatives, and its competent authorities and any relevant resolution authorities, the right to access information about, and to audit, the Service provided to the Customer, to the extent required for the Customer to monitor our performance under this Addendum and to meet its obligations under DORA. These rights are exercised in the tiered manner described below, and the level of access is not impeded by this Section.

(b) Tier 1 — documentary assurance first. In the first instance, and to satisfy most information and audit needs, we will make available documentation about the Service, completed security and due-diligence questionnaires, the Security Overview, our control matrix and gap list, and any third-party reports or certifications we hold from time to time, and we will support pooled or consolidated audits organized among multiple customers of the Service. Pooled audits and third-party attestations satisfy this documentary tier if and when such attestations exist; as of the effective date none exists, and documentary assurance is provided through questionnaires and this Addendum's referenced documents. We do not currently hold a SOC 2 attestation or an ISO 27001 certificate; we maintain a documented readiness program, and we will provide its outputs in this tier.

(c) Tier 2 — direct audit where required. Where documentary assurance is insufficient and a direct audit is required by the Customer's competent authority, or is otherwise mandated by DORA, we will grant the Customer (or an independent auditor it appoints who is not our competitor and who is bound by confidentiality) the right to conduct a direct audit of the Service, subject to: (i) reasonable advance written notice, normally at least thirty days except where a shorter period is required by a competent authority or by an emergency; (ii) a limit of one audit in any twelve-month period, except where more frequent audits are required by a competent authority or follow a material ICT incident affecting the Customer; (iii) conduct during business hours and in a manner that does not disrupt the Service or compromise the security or confidentiality of other customers' data or systems; (iv) no access to the data, systems, or premises of any other customer; and (v) the Customer bearing its own and our reasonable costs of the audit. Because the Service runs on third-party cloud infrastructure that 403 Finance does not own, on-premises inspection of that infrastructure is provided through the audit and certification rights we hold from our sub-contractors and through the documentary assurance in Tier 1.

(d) Cooperation with competent authorities. We will cooperate directly with the Customer's competent authorities and resolution authorities to the extent legally required, including by providing information and access relating to the Service where a competent authority so requires under DORA, except to the extent such cooperation would place 403 Finance in violation of United States law or conflicting legal process, in which case the parties will cooperate in good faith to find a lawful means of satisfying the requirement.

(e) Confidentiality of audit. All information obtained through the exercise of the rights in this Section is Confidential Information under the Terms and may be used only for the purpose of the audit or the discharge of the Customer's or an authority's regulatory functions.

8. Sub-Contracting

(DORA Article 30(2)(a) and 30(3)(d))

(a) Current sub-contractors. The ICT sub-contractors that 403 Finance relies on to provide the Service are the sub-processors identified in the Sub-Processor List maintained under the DPA — currently Cloudflare (edge, TLS, and compute), Neon (metadata and encrypted batch ciphertext at rest), Stripe (billing identity and metering, which never receives Message Content), Reoon (signup email validation), and Emailit (transactional email). The Sub-Processor List describes the function each performs.

(b) Notification and objection. The sub-processor list, the 15-day advance notice of a new or replacement sub-processor, and the Customer's right to object under the DPA together constitute the sub-contracting notification mechanism for the purposes of this Addendum. We will notify the Customer in advance of any material change to the sub-contracting arrangements that support the Service, including any change of a sub-contractor that provides an ICT service supporting a function the Customer has assessed as critical or important, so that the Customer can assess the change and, if applicable, exercise its objection right under the DPA before the change takes effect.

(c) Responsibility for sub-contractors. We remain responsible for the performance of the Service notwithstanding our use of sub-contractors, and we impose data-protection and security obligations on each sub-processor as required by the DPA.

9. Termination and Exit

(DORA Article 30(2)(h) and 30(3)(f))

(a) Customer's termination rights. In addition to the termination rights in the Terms or the MSA, the Customer may terminate this Addendum and the affected subscription where required to enable the Customer to comply with DORA, including where: (i) 403 Finance is in material breach of applicable laws, regulations, or contractual terms; (ii) circumstances are identified, through the Customer's ongoing ICT third-party risk monitoring, that could alter the performance of the functions provided through the Service, including material changes that affect the arrangement or 403 Finance's situation; (iii) there are evidenced weaknesses in 403 Finance's management of ICT risk relating to the Service, in particular in the accessibility, integrity, or confidentiality of data; or (iv) the Customer's competent authority can no longer effectively supervise the Customer as a result of the arrangement. These grounds correspond to the minimum termination rights contemplated by Article 28(7) of DORA.

(b) No data-migration dependency on exit. Because the Service is stateless, exit does not depend on migrating an accumulated store of the Customer's message data away from 403 Finance: the Customer already holds its own Message Content and Output. The two enumerated statelessness exceptions purge on their short retention windows or on demand, as described in Section 3(b).

(c) Transition assistance. On the Customer's request in connection with termination or exit, and to support an orderly wind-down without undue disruption to the Customer's business or its regulatory compliance, we will: (i) continue to provide the Service during an exit or transition period of up to ninety (90) days from the effective date of termination where the Customer requests it, on the commercial terms then in effect; (ii) export the Customer's available Usage Metadata in a commonly used machine-readable format; (iii) on request, certify in writing the purge of any batch ciphertext and idempotency-cache entries associated with the Customer following expiry of their retention windows; and (iv) provide reasonable cooperation and information to support the Customer's transition to an alternative arrangement or to bringing the function back in-house, at the pre-agreed rates set out in the Terms or the applicable Order.

(d) Effect of termination. On termination, the effect-of-termination provisions of the Terms apply, including revocation of API Credentials and purge of any Message Content or Output held in the idempotency cache or batch job store within the applicable retention windows or sooner on request.

10. Financial-Entity Specific Terms

(a) No impediment to the Customer's compliance. Nothing in this Addendum, the Terms, the MSA, or the AUP is intended to, or will be construed to, impede the Customer's compliance with DORA or with the requirements of its competent authorities. Where a provision of another agreement would have that effect for a matter this Addendum covers, this Addendum prevails to the extent necessary to remove the impediment.

(b) Regulator notification and consultation. We will provide the information and cooperation reasonably necessary for the Customer to meet any obligation to notify or consult its competent authority about the arrangement with 403 Finance, including in connection with the Customer's register of information and any pre-outsourcing notification the Customer's regulatory regime requires.

(c) Recordkeeping. We will retain Usage Metadata and the operational records relating to the Service in accordance with the Terms and the Privacy Policy, and we will make relevant records available to the Customer as provided in Sections 5 and 7 to support the Customer's own recordkeeping obligations.

(d) Order of precedence. For the matters this Addendum covers, this Addendum prevails over the Terms, the MSA, and the AUP in the event of a conflict. The DPA continues to control for data-protection specifics, including the technical and organizational measures, sub-processing, international transfers, and personal-data breach notification. A signed Enterprise agreement and its Order continue to sit above this Addendum in the order of precedence except as to the DORA-specific matters this Addendum expressly governs.

11. Definitions and Interpretation

(a) DORA terms. Terms used in this Addendum that are defined in DORA — including "financial entity," "ICT third-party service provider," "ICT services," "ICT-related incident," "critical or important function," and "competent authority" — have the meanings given to them in DORA, and this Addendum is to be interpreted consistently with DORA.

(b) Other defined terms. Terms defined in the Terms or the DPA and used in this Addendum have the meanings given to them there. In the event of a conflict between a definition in this Addendum and a definition in the Terms, the definition in this Addendum controls for the matters this Addendum covers.

(c) Analogous regimes. References in this Addendum to DORA and its Articles include, where the context requires and to the extent applicable to the Customer, the equivalent provisions of the EBA, EIOPA, or ESMA outsourcing or ICT third-party risk-management guidelines that apply to the Customer.

(d) No expansion of substantive obligations. This Addendum records how the Service and 403 Finance's existing commitments meet the contractual requirements of Articles 28 and 30 of DORA. It does not expand the functional scope of the Service, and it does not create availability, performance, or security warranties beyond those in the Terms and the DPA.

Change History

Back to the Transmute legal center