Contract schedules: draft clauses for counsel

Status: drafts for a bank's counsel. No bank has agreed these terms. They are written so each promise matches what the product actually does, and each clause names the mechanism that makes it true. Not legal advice. Liability caps and insurance are deliberately absent: no cover is held, and none is described.

Schedule A — Audit and access#

1. Continuous verification, without notice. The Customer and its competent authority may verify, at any time and without notice to the Provider:

   • every signed record against the Provider's published keys;
   • the verdict log's consistency;
   • the refusal list.

   All of it offline, using the Provider's published verifier or their own implementation of the protocol specification. (Mechanism: /jwks, /anchor/*, /cannot, the conformance vectors.)

2. Supervisory seat. On request, the Provider grants the Customer's competent authority read access to the supervisor feed for the Customer's corridors. (/supervisor/feed)

3. On-site or documentary audit. On 30 days' written notice, or immediately where required by a competent authority, the Provider makes available:

   • its operating procedures;
   • the release provenance for the running version;
   • the evidence behind any statement on its published pages.

4. No audit of what the Provider does not hold. The Provider cannot produce trade values, bands, corridor secrets or customer identities; the Customer holds them. This is stated so an audit request is not frustrated by an impossibility.

Schedule B — Exit and portability#

1. Standing portability. Every verdict is signed and delivered to the parties when made. The Customer holds its own records throughout and is never dependent on the Provider to read them.

2. On termination, within 30 days, the Provider delivers to the Customer:

   • the Customer's governance events;
   • the verdicts on which its legs authenticated, as signed JSON with an export manifest;
   • the corridor passport for each of its corridors.

   (/audit/export, mirror-passport)

3. Succession. The Customer's corridors may be moved to a successor operator. The handover is itself a signed, verifiable record. (mirror-succession, /succession/verify)

4. Continuity of verification. Old verdicts remain verifiable after exit. The keys are published, and the verification escrow bundle is available to the Customer and its authority. (/archive)

Schedule C — Data location and sub-processors#

1. Storage location. The operator's durable state is stored in the European Union (AWS eu-central-1, through the Provider's database sub-processor). (See data residency.)

2. Processing location. The Provider processes the Customer's requests only in the European Union: in a compute object its edge-compute sub-processor restricts to the EU jurisdiction. If that object is unreachable, the request is refused, and it is not processed elsewhere. Only commitments, signatures and governance data are processed; the raw-data wall is enforced in code. (GET /residency, signed; meets(record, "eu"); /cannot: raw_value)

3. What the location commitment excludes. It does not cover:

   • the network hop at which a request first reaches the sub-processor, which forwards it unread;
   • identifiers the sub-processor logs for billing and debugging.

   Both are listed in the signed record's not_covered.

4. Verification. The Customer may check the processing location at any time, by verifying the signed residency record against the Provider's published keys. A record that does not meet the EU jurisdiction is a breach of C.2.

5. Sub-processor changes. The Provider notifies the Customer of any new sub-processor at least 30 days before use, and the Customer may object. (Register: sub-processors.)

Schedule D — Incidents and cooperation#

1. Assistance. In an ICT-related incident affecting the service, the Provider gives the Customer the facts it needs for its own reporting, without undue delay:

   • timeline;
   • affected corridors, in counts;
   • error codes from the published taxonomy.

   The Customer's own signed records remain the primary evidence. (/signals.json, incident support)

2. Cooperation with authorities. The Provider cooperates fully with the Customer's competent and resolution authorities. It cannot produce data it does not hold (A.4).

3. Termination rights and notice periods are commercial terms left to the parties.

Cross-reference: DORA Art. 30(2) lists the elements a contract for ICT services must contain. The table above maps several of them to mechanisms. Mapping every element and drafting the final text is counsel's work.