Institutional Engagement · §V25.2

Build. Test. Validate.

MITHQAL is seeking regulated institutions, monetary authorities, regulators, infrastructure providers and independent assurance institutions for controlled technical review, sandbox testing, integration assessment and pilot design.

Engagement is subject to institutional, legal, regulatory, technical and jurisdictional review.

Express Institutional Interest View Pilot Requirements

CONTROLLED INSTITUTIONAL DOCUMENT • NOT A LICENSE • NOT A LEGAL OPINION.

§2 · Engagement Scope

Institutions MITHQAL is seeking to engage

MITHQAL is not advertising partnerships and is not offering a token. The institutions below describe the categories MITHQAL is seeking to engage for controlled technical review, sandbox testing, integration assessment and pilot design. Engagement is selective, evidence-led and jurisdiction-specific.

Central Banks / Monetary Authorities

Who they are: Sovereign monetary authorities responsible for currency issuance, reserve management, payment system oversight and financial stability.
What MITHQAL may ask: Review of the MTQ settlement model against monetary policy objectives, reserve-backing architecture, and systemic risk implications.
Appropriate engagement: Architecture Review · Regulatory/Legal Review

Regulated Banks

Who they are: Licensed deposit-taking institutions subject to prudential supervision, capital requirements and AML/CFT obligations.
What MITHQAL may ask: MBG integration assessment, ISO 20022 compatibility, KYC/KYB/AML/sanctions interface review, and pass-through settlement evaluation.
Appropriate engagement: Bank Integration Pilot · Settlement Pilot · Sandbox Testing

Regulated Financial Institutions

Who they are: Non-bank financial institutions including money service businesses, treasury providers and authorized FX intermediaries.
What MITHQAL may ask: Settlement corridor evaluation, FX conversion interface, liquidity assessment and non-bank integration model review.
Appropriate engagement: Architecture Review · Settlement Pilot

Payment / Clearing / Settlement Infrastructure

Who they are: Operators of RTGS, ACH, instant payment, clearing and settlement systems that process interbank transfers.
What MITHQAL may ask: Multi-rail interoperability assessment, settlement finality model review, and infrastructure compatibility evaluation.
Appropriate engagement: Architecture Review · Integration Assessment

Government / Sovereign Infrastructure Authorities

Who they are: Sovereign entities responsible for national payment infrastructure, digital identity, trade finance and sovereign settlement systems.
What MITHQAL may ask: Sovereign settlement corridor review, jurisdictional evaluation and public infrastructure interoperability assessment.
Appropriate engagement: Architecture Review · Regulatory/Legal Review

Financial Regulators / Supervisory Authorities

Who they are: Regulatory bodies overseeing banking, payments, securities, digital assets and financial conduct within their jurisdiction.
What MITHQAL may ask: Classification review, licensing perimeter evaluation, liability chain assessment and sandbox framework engagement.
Appropriate engagement: Regulatory/Legal Review · Sandbox Testing

Banking Technology / Payment-Rail Providers

Who they are: Technology firms providing core banking systems, payment gateways, ISO 20022 messaging and treasury infrastructure.
What MITHQAL may ask: MBG adapter compatibility, API/schema review, ISO 20022 field mapping and technical integration assessment.
Appropriate engagement: Architecture Review · Bank Integration Pilot

Cybersecurity / Independent Assurance Institutions

Who they are: Independent security firms, auditors and assurance providers specializing in financial infrastructure security.
What MITHQAL may ask: Security architecture review, finality enforcement audit, penetration testing scope and reconciliation evidence verification.
Appropriate engagement: Independent Assurance · Sandbox Testing

Legal / Regulatory Institutions

Who they are: Law firms, regulatory advisors and legal institutions specializing in financial regulation, payments law and cross-border settlement.
What MITHQAL may ask: Legal classification review, jurisdictional liability analysis, regulatory perimeter assessment and governing law evaluation.
Appropriate engagement: Regulatory/Legal Review

Standards / Research Institutions

Who they are: Academic, research and standards organizations studying monetary architecture, payment systems and settlement theory.
What MITHQAL may ask: Architecture review, comparative analysis, theoretical validation and publication of independent findings.
Appropriate engagement: Architecture Review · Independent Assurance

§3 · Engagement Matrix

Engagement types

Each engagement type is a structured technical activity with defined inputs, MITHQAL-provided artefacts and the evidence expected at closure. All engagement types are currently PROPOSED — none has been activated. Activation requires documented institutional authorization.

Architecture Review

PROPOSED

Review the MITHQAL architecture alongside institutional infrastructure to assess compatibility, boundary design and integration feasibility.

Institution inputs: Existing architecture overview, integration points, constraints and non-production environment description.
MITHQAL inputs: Technical Architecture Package, Bank Boundary Architecture, MBG Integration Model, API/Schema Documentation.
Expected evidence: Architecture review notes, compatibility assessment, integration gap analysis.

Regulatory / Legal Review

PROPOSED

Evaluate classification, licensing perimeter, liability chain and jurisdiction-specific requirements.

Institution inputs: Jurisdiction, regulatory framework, licensing requirements, legal entity structure.
MITHQAL inputs: Legal liability framework, licensing/entity matrix, jurisdiction registry (all PENDING), MTQ legal nature.
Expected evidence: Regulatory classification opinion, licensing perimeter assessment, liability analysis.

Sandbox Testing

PROPOSED

Conduct controlled testing in a regulator, bank, innovation sandbox or equivalent non-production environment.

Institution inputs: Sandbox environment access, test identities, synthetic data, test accounts.
MITHQAL inputs: Sandbox test scenarios, adversarial test scenarios, reconciliation test plan, DR/failure-injection test plan.
Expected evidence: Test execution reports, reconciliation evidence, security assessment, incident response validation.

Bank Integration Pilot

PROPOSED

Evaluate MBG integration through API, ISO 20022, host-to-host, SFTP, treasury and ERP interfaces where applicable.

Institution inputs: Technical architecture contact, existing integration capabilities, non-production environment, test corridor.
MITHQAL inputs: MBG Integration Model, API/Schema Documentation, MTQSettlementInstruction, Issuance State Machine.
Expected evidence: Integration test results, API compatibility report, ISO 20022 field mapping validation.

Settlement Pilot

PROPOSED

Controlled institutional testing under the initial one-institution / one-jurisdiction / one-corridor model.

Institution inputs: Named institutional sponsor, test corridor, settlement scenario, payment/finality reference mechanism.
MITHQAL inputs: Finality-Before-Mint Control Specification, Protected Backing Cell Model, Three-Book Separation Model.
Expected evidence: Settlement execution records, reconciliation results, finality verification evidence.

Independent Assurance

PROPOSED

Review security, finality, reconciliation, resilience, evidence and controls.

Institution inputs: Security assessment methodology, audit framework, evidence requirements.
MITHQAL inputs: Security Architecture, Privacy Architecture, Resilience and Failure Semantics, Five-Way Reconciliation Model.
Expected evidence: Independent assurance report, security assessment, reconciliation verification, resilience validation.

§4 · Institutional Readiness

What we need from the institution

The checklist below itemises the inputs MITHQAL typically requests from an institution during intake. Requirements vary by institution, jurisdiction and engagement type. These items are display-only — they describe scope, not a contract.

Institutional

7 items

[1] Named institutional sponsor
[2] Named technical contact
[3] Named compliance contact
[4] Named legal/regulatory contact
[5] Legal entity identity
[6] Institution type
[7] Jurisdiction

Regulatory

4 items

[8] Regulatory/supervisory authority
[9] Regulatory status
[10] Sandbox / innovation framework information
[11] Legal/regulatory review path

Technical

5 items

[12] Technical architecture contact
[13] Existing integration capabilities
[14] Non-production/sandbox environment
[15] Synthetic test identities/data
[16] Test accounts where appropriate

Settlement

3 items

[17] Test corridor
[18] Settlement scenario
[19] Payment/finality reference mechanism

Compliance

3 items

[20] KYC/KYB interface
[21] AML/CFT interface
[22] Sanctions interface

Assurance

2 items

[23] Authority attestation
[24] Funds-availability attestation

Security

3 items

[25] mTLS/certificate requirements
[26] HSM/MPC requirements
[27] Security/network requirements

Reconciliation

1 item

[28] Reconciliation requirements

Privacy

1 item

[29] Privacy/data-residency requirements

Resilience

1 item

[30] Business continuity / disaster-recovery requirements

Authorization

3 items

[31] Formal pilot authorization/agreement
[32] Acceptance criteria
[33] Responsible institutional signatories

Security notice

Do not submit passwords, private keys, seed phrases, customer credentials, confidential customer information, production banking credentials, or other secrets. Initial contact should contain only institutional and non-sensitive information.

§5 · MITHQAL Inputs

What MITHQAL provides

MITHQAL can provide, subject to readiness and formal agreement, the artefacts below for controlled review, sandbox testing and integration assessment. MITHQAL cannot and will not promise: licensing, regulatory approval, funding, liquidity, custody, financial guarantees, institutional authorization, or production deployment.

Technical Architecture Package

Bank Boundary Architecture

MBG Integration Model

API / Schema Documentation

MTQSettlementInstruction

Issuance State Machine

Finality-Before-Mint Control Specification

Protected Backing Cell Model

Three-Book Separation Model

Five-Way Reconciliation Model

Security Architecture

Privacy Architecture

Resilience and Failure Semantics

Sandbox Test Scenarios

Adversarial Test Scenarios

Reconciliation Test Plan

DR / Failure-Injection Test Plan

Pilot Acceptance Criteria

Institutional Readiness Framework

Jurisdiction-Specific Integration Assessment

What MITHQAL will not promise

Licensing · Regulatory approval · Funding · Liquidity · Custody · Financial guarantees · Institutional authorization · Production deployment. Any pilot is a controlled test, not a production commitment.

§6 · Jurisdiction Support

Bring your jurisdiction into the evaluation

MITHQAL evaluates jurisdictions individually. A jurisdiction becomes a candidate only after institutional, legal, regulatory, technical and corridor reviews are completed. The structured inputs below describe the information MITHQAL typically requires to scope a jurisdiction evaluation. They are display-only and non-functional — submit through the formal intake form below.

Free-text jurisdiction entry

Allow regulator/authority fields to be entered as institutional free text. MITHQAL does not maintain a public regulatory directory. Do not enter confidential information here or in the intake form.

CountrySovereign jurisdiction under evaluation.RegulatorFree-text. Do not enter confidential information.Central BankMonetary authority for the jurisdiction (if distinct).Local CurrencyISO 4217 code where applicable.Proposed CorridorOrigin / destination settlement corridor under evaluation.Payment Railse.g. RTGS, ACH, instant payment, host-to-host.Messaging Standardse.g. ISO 20022, SWIFT MT.Sandbox Available?Regulatory FrameworkBrief overview only. No legal opinions.Data ResidencyConstraints on where institutional data may reside.Legal QuestionsOpen questions for legal review.Regulatory QuestionsOpen questions for regulatory review.Technical QuestionsOpen questions for technical review.Integration QuestionsOpen questions for integration review.Expected TimelineIndicative only. Not a commitment.Institution Role

§7 · Jurisdiction Workflow

Jurisdiction evaluation workflow

A jurisdiction advances through eight evaluation states. None of these states constitutes approval. Each transition is gated by documented evidence.

1
SUBMITTED
Jurisdiction evaluation request received. This is an evaluation state, not an approval.
2
INITIAL REVIEW
MITHQAL has begun reviewing the submission. No institutional commitment implied.
3
JURISDICTION ASSESSMENT
Assessing jurisdictional regulatory environment, infrastructure and corridor feasibility.
4
LEGAL / REGULATORY REVIEW
Legal classification and regulatory perimeter under evaluation. No license implied.
5
TECHNICAL REVIEW
Technical integration, API and rail compatibility under assessment.
6
SANDBOX CANDIDATE
Identified as a potential sandbox testing candidate. Not yet validated.
7
PILOT CANDIDATE
Identified as a potential pilot candidate. Subject to formal authorization.
8
INSTITUTIONALLY VALIDATED
Validated through documented institutional review. Requires authorized institutional evidence.

Hard rule

A jurisdiction must NEVER become "supported" simply because someone submits a form. Each transition is gated by documented institutional evidence and review.

§8 · Institutional Intake

Express institutional interest

The intake form below is the formal channel for institutional interest. Submission does not constitute an engagement, an offer, a partnership or any obligation on either party. It is an evaluation request only.

Loading institutional intake form…

Security notice

§9 · Direct Contact

Email MITHQAL directly

For institutions unable or unwilling to use the intake form, MITHQAL accepts initial institutional contact by email. Initial contact should contain only institutional and non-sensitive information.

Institutional email

meltonsy@icloud.com

Use this address for initial institutional contact only. Do not attach credentials, customer information or other secrets.

Email MITHQAL Directly Open intake form

Security notice

§10 · Pilot Model

The initial pilot model

The initial pilot is scoped narrowly to enable controlled testing. Broader treasury holding is outside the initial pilot scope. Each stage gates the next.

1
ONE REGULATED INSTITUTION
2
ONE JURISDICTION
3
ONE CORRIDOR
4
INSTITUTIONAL CORPORATES
5
CONTROLLED TEST ENVIRONMENT
6
MTQ PASS-THROUGH SETTLEMENT
7
RECONCILIATION
8
SECURITY / RESILIENCE TESTING
9
INDEPENDENT / INSTITUTIONAL REVIEW

Scope boundary

Broader treasury holding is outside the initial pilot scope. The pilot evaluates pass-through settlement, reconciliation and security semantics — not custody of treasury assets.

§11 · Review Package

Institutional review package

The review package below is the structured set of MITHQAL review artefacts and templates. These are MITHQAL review artefacts — not approved by any institution. They are provided to institutions for controlled technical review and pilot scoping.

Item 01

Architecture Review Package

Item 02

Integration / API Package

Item 03

Security Questionnaire

Item 04

Legal / Regulatory Questionnaire

Item 05

Pilot Test Plan

Item 06

Test-Case Matrix

Item 07

Reconciliation Evidence Plan

Item 08

Incident / DR Test Plan

Item 09

Acceptance Criteria

Item 10

Institutional Sign-Off Record

Review artefacts only

These are MITHQAL review artifacts/templates. Not approved by any institution. They are inputs to a controlled review process, not artefacts of an activated pilot.