Escrow on Demand: Bank-Operated Digital Escrow for Everyday Transactions

A Product and Architecture Thesis for x-change

• Status: Exploratory product thesis; revised for public, transaction-funded access and market positioning.
• Date: 2026-11-03.
• Document type: Research-style position paper and product thesis.
• Evidence status: No empirical study or completed legal classification is claimed.
• Working model: A bank offers and operates the product; ODTI licenses x-change and provides separately agreed implementation or support services.
• Primary access model: Public on-demand issuance without a purchaser login, platform Account, or reusable platform spending balance; identification and authorization requirements remain applicable.

Drafting Discipline

Develop each section separately. Distinguish documented facts, assumptions,
architectural proposals, hypotheses, and unresolved questions. Cite primary
sources for legal propositions and versioned package evidence for implementation
claims. Record observations only when supported by identifiable evidence.

The term "digital escrow" is a working product concept. It does not establish
institutional authority, legal segregation, regulatory exemption, or the legal
character of a Pay Code. This paper is not legal advice or a compliance opinion.

In this paper, account-free describes the purchaser's platform experience:
no mandatory platform Account or reusable spending balance. It does not mean
anonymous access, absence of customer records, or absence of institutional
bank accounts and Treasury accounting. Escrow on demand is the proposed
service positioning, not a claim that escrow, guest checkout, or conditional
payment has been newly invented.

1. Abstract

Financial transactions frequently require an interval between committing funds and authorizing payment. Faster transfer infrastructure does not independently resolve the conditions, evidence, and decisions governing that interval. This paper proposes escrow on demand: a bank-operated digital escrow service built on x-change's existing public, transaction-funded issuance path.

The conceptual model centers on a funded conditional obligation. A purchaser would access a public browser flow and fund a specific issuance order, including applicable charges, without opening a platform Account or prefunding a reusable wallet. A Pay Code would identify or provide controlled access to the associated obligation. The proposed escrow layer would connect the parties' agreement, continuing commitment of funds, release conditions, disputes, and authorized payment or refund. Existing Client Funds remain an optional institutional path, not a prerequisite for public access.

The paper draws on selected regulatory sources, founder-authored monographs, published competitor materials, and x-change documentation and source inspection. Existing bank escrow, Philippine retail services, and international guest-buyer flows rule out a general claim of category novelty. The market hypothesis is instead that standardized, bank-administered escrow can become accessible to occasional users outside a proprietary wallet or marketplace. Five hypotheses address customer utility, architectural fit, operational integrity, bank operability, and commercial feasibility.

The reviewed implementation supports public, full-amount issuance funding and guest-order access; it does not establish a complete escrow lifecycle. All five product-level hypotheses remain unresolved. Legal characterization depends on the actual agreements, institutional roles, and operation; transaction-specific funding alone does not establish escrow status or regulatory exemption.

The paper contributes an examinable product model and validation agenda. Further work should select an initial use case, define the bank’s undertaking, establish institutional arrangements, and evaluate the resulting service against explicit criteria.

Keywords: escrow on demand; digital escrow; account-free access; conditional settlement; Pay Code; transaction-specific funding; banking; x-change.

2. Introduction

2.1 Payment Instructions and the Separation of Intent from Settlement

The use of instructions to arrange payment long predates digital finance. Checks illustrate a durable distinction: a person can communicate an instruction to pay without physically delivering cash at the same moment. Issuance, presentation, verification, and eventual payment are separate events. This separation provides a useful starting point for examining digital escrow.

Three practical concerns motivate this paper. The first is timing: an obligation may be created before payment should occur. The second is logistics: parties may transact across distance without transporting currency themselves. The third is security: payment should depend on established authority and appropriate verification. These concerns remain relevant even where electronic transfers can move funds almost immediately.

Financial institutions perform an essential coordinating role within this separation. They receive and authenticate instructions, establish whether payment is authorized, and arrange execution through their accounts and settlement infrastructure. The instruction expresses an intended financial action; the institution determines whether and how that action may proceed.
The check is a functional analogy, not the proposed product's legal identity. The Negotiable Instruments Law requires an unconditional promise or order for negotiability and states that an instrument payable upon a contingency is not negotiable. A release condition such as buyer acceptance must not be presented as carrying the legal characteristics of an ordinary negotiable check. Act No. 2031, Sections 1 and 4

2.2 From Faster Transfers to Governed Obligations

The conceptual foundation of this study derives from Lester B. Hurtado’s x-change monographs. In When Money Adapts to People, Hurtado interprets the paper check as an example of separating a financial obligation from its eventual settlement. That interpretation motivates an architectural question: can a financial instruction remain useful while the means of presenting, verifying, and executing it become digital? Hurtado, When Money Adapts to People

The companion essay, x-change: A Founder’s Update, describes how a practical disbursement problem developed into a broader concern with entitlement, evidence, approvals, and exceptions. Its central observation is that the transfer itself represents only one stage of a financial obligation’s lifecycle. This paper adopts that observation as a research premise rather than an independently established finding. Hurtado, x-change: A Founder’s Update

The distinction matters because transfer speed cannot determine whether a recipient has become entitled to payment. A transaction may require delivery, inspection, identity verification, documentary presentation, or another agreed event. Faster execution helps after authority has been established; a separate mechanism must govern the conditions preceding it.

2.3 Escrow on Demand as a Product Hypothesis

This paper proposes a bank-operated digital escrow service built around transaction-specific funding and explicit release conditions. A customer would fund a particular transaction, and the bank would administer the associated obligation under an agreement identifying the relevant parties, their rights, and the conditions governing payment or return of funds.

A Pay Code would identify or provide access to the associated settlement instruction. Its presentation would initiate the required verification process. Possession of the code alone would not override the agreement’s release conditions.

The existing public /x/auto-generate path supplies the transaction-funded entry point: the purchaser need not log in or open a platform Account, and public issuance uses full-amount funding rather than a customer's existing Client Funds. The proposed escrow product would extend that foundation, not replace it with wallet onboarding. A separate authenticated path may reserve existing Client Funds; it is not the primary public model.

The recommended initial candidate is a one-time domestic PHP purchase of specified physical goods, with one full release and bounded transaction values and holding periods. A buyer funds the agreed purchase; the seller verifies the bank's commitment before delivery; release follows attributable buyer acceptance or the agreed resolution process. Appendix E develops this candidate. It is not an approved pilot or a claim that all retail transactions are suitable.

This proposal uses digital escrow as a working product concept. Whether a particular implementation constitutes escrow, another banking service, or overlapping regulated activities must be evaluated from its actual agreements, institutional roles, and operation.

2.4 Institutional Ownership and Architectural Responsibility

Under the proposed model, the participating bank owns and operates the financial product. It establishes the customer agreement, administers the funds, governs release decisions, and assumes the obligations assigned to it by the applicable arrangement. ODTI licenses x-change and supplies implementation or support services within separately defined responsibilities.

The resulting architecture must connect each instruction to its funding evidence, governing conditions, approvals, execution result, and accounting records. It must also explain what happens when a transaction expires, is cancelled, becomes disputed, or cannot be completed. These relationships form part of the product itself: they determine whether the institution can explain and reconstruct its actions.

2.5 Purpose and Contribution of the Study

This study investigates whether x-change can support an accessible bank-operated digital escrow service while preserving institutional control, transaction-specific accountability, and auditable settlement. It examines the relationship between established financial practices and the proposed digital lifecycle, identifies architectural and contractual gaps, and develops criteria for subsequent evaluation.

The intended contribution is a product and architecture thesis that can be challenged through documentary research, bank assessment, legal analysis, customer inquiry, and controlled operational evidence. Its central proposition is that modern financial infrastructure can improve how obligations are governed, alongside improving how quickly funds move.

3. Research Questions and Objectives

3.1 Central Research Question

Can a bank-operated service extend x-change's public, transaction-funded issuance path into useful digital escrow for eligible occasional users without requiring a purchaser login, platform Account, or reusable platform spending balance?

This question connects the proposed customer experience with the institutional obligations necessary to support it. Its investigation requires examining how funds are received and administered, how payment authority is established, and how the rights of the parties change throughout the transaction.

3.2 Supporting Research Questions

Financial relationship. When a customer pays for a Pay Code, what obligation does the bank assume? Does it hold funds as an escrow agent, issue a payment undertaking, or enter another identifiable arrangement? Who is entitled to the funds before release, and how does that entitlement change upon settlement, cancellation, expiry, or dispute?

Conditions and authority. Which events authorize release, and who may establish that those events occurred? How should the service distinguish identity verification, contractual performance, customer approval, and the bank’s authorization to execute payment?

Transaction-specific funding. Can each issuance remain tied to identifiable funding and a defined obligation throughout its lifecycle? Can excess payments, refunds, and failed transactions be resolved without creating an unintended reusable spending balance?

Institutional roles. What responsibilities belong to the product-operating bank, any separate escrow or settlement institution, and ODTI? What authority and contractual arrangements does each proposed role require?

Architectural adequacy. Which requirements can the documented x-change architecture support, and which require further development? Can the system prevent conflicting uses of committed funds, handle uncertain settlement outcomes, and preserve a complete explanation of each transaction?

Customer and commercial value. Which customers would benefit from the service, and for which transactions? Would its convenience, protection, cost, and accessibility justify adoption compared with existing alternatives?
Market access. Do account-opening, wallet, marketplace, documentation, or setup requirements discourage otherwise eligible users from existing services? Does removing selected barriers create additional completed transactions, rather than merely shifting users between comparable providers?

3.3 General Objective

To develop and evaluate a product and architecture model for bank-operated digital escrow powered by x-change, with explicit treatment of customer rights, institutional responsibilities, funding, conditional release, settlement, and evidence.

3.4 Specific Objectives

1. Define the proposed service and its intended customer use cases.
2. Compare its obligations with those arising under escrow and related banking instruments.
3. Model the lifecycle from funding and issuance through settlement or another authorized disposition.
4. Identify the custody, entitlement, authority, and accounting relationships at each stage.
5. Map product requirements to documented x-change capabilities and identify gaps.
6. Evaluate normal and adverse scenarios, including disputes, duplicate claims, expiry, cancellation, and uncertain provider outcomes.
7. Establish criteria for customer research, bank assessment, legal review, and a controlled pilot.
8. Identify evidence that would support, require revision of, or contradict the proposed model.

3.5 Standard of Evaluation

The study will treat product usefulness, architectural adequacy, operational integrity, and legal characterization as related but distinct subjects of evaluation. Evidence supporting one does not automatically establish the others.

A technically successful demonstration would show that a defined workflow can execute under specified conditions. Customer research would address whether that workflow solves a meaningful problem. Institutional and legal review would address the proposed roles, obligations, and authority. Operational evidence would be needed to assess reliability and control in practice.

The research must remain open to alternative outcomes. Digital escrow may prove suitable for some use cases, while others may be better structured as a different bank payment service. Either result would advance the study if supported by clear reasoning and evidence.

4. Review of Related Literature and Regulatory Sources

4.1 Intellectual Foundation: Financial Obligations Before Settlement

Hurtado’s x-change monographs provide the conceptual starting point for this study. When Money Adapts to People interprets the check as an instruction that separates the creation of an obligation from its eventual settlement. x-change: A Founder’s Update develops the related proposition that entitlement, evidence, approvals, and exceptions form a lifecycle surrounding payment. Together, these essays motivate an architecture in which the obligation and its governing conditions remain explicit before execution occurs. Hurtado, When Money Adapts to People, Hurtado, x-change: A Founder’s Update

The monographs are founder-authored conceptual sources. Their role in this study is to explain the origin and intended direction of the architecture. Their claims about customer needs, market opportunity, and operational effectiveness require evaluation through additional sources and empirical evidence.

4.2 Escrow as Conditional Administration of Entrusted Property

BSP Circular No. 609 describes escrow within its Financial Reporting Package for Trust Institutions. Its definition concerns agency agreements under which a trust institution holds money, securities, or property deposited by a principal, with eventual delivery to a third party contingent on an event or an action by the principal, the third party, or both. BSP Circular No. 609, item (6), “Escrow”

For this study, the definition identifies a relationship among entrusted property, an administering institution, an intended recipient, and a release condition. It provides a basis for examining the proposed product’s agreements and lifecycle. Its reporting context must also be preserved: the definition alone does not determine the classification or permitted provider of every conditional payment service.

An architectural reservation records that an amount has been committed to an obligation. Whether that reservation implements an escrow arrangement depends on the underlying rights and duties. The research must therefore examine both the accounting representation and the agreement that gives it meaning.

4.3 Related Instruments: Instructions, Undertakings, and Documentary Conditions

Checks, manager’s checks, money orders, documentary credits, and guarantees provide useful comparisons because each connects an instruction or undertaking with an eventual payment. Their differences concern who owes payment, the conditions of that obligation, and the recipient’s rights.

Documentary credits illustrate a bank undertaking linked to the presentation of stipulated documents. The United States International Trade Administration describes a letter of credit as a bank commitment to pay when its specified terms are met through the required documentary presentation. This mechanism distinguishes documentary compliance from a general determination that the underlying commercial relationship has been satisfactorily performed. International Trade Administration, Letters of Credit and Documentary Collection

Demand guarantees introduce another distinction. Under the ICC framework for guarantees subject to URDG 758, the guarantor’s undertaking is independent of the underlying relationship and responds to a complying demand. Those rules apply when incorporated into the instrument; they should not be assumed to govern every bank guarantee. ICC Academy, Understanding Demand Guarantees: A Guide to URDG 758

These comparisons suggest that the study must specify whether a proposed Pay Code represents access to entrusted funds, evidence of a bank undertaking, or an instruction operating under another arrangement. Manager’s checks and money orders remain subjects for further Philippine source review before detailed legal comparisons are drawn.

4.4 Transaction-Specific Funding and E-Money

The proposed service distinguishes funding a particular obligation from maintaining a reusable platform spending balance. That distinction is relevant to product design, but it cannot independently determine regulatory treatment.

BSP Circular No. 1166 defines e-money through several characteristics involving the account, prefunding, acceptance, issuance against received funds, the claim on the issuer, and withdrawal or transfer functionality. Evaluation therefore requires examining the complete arrangement rather than relying on the presence or absence of the word “wallet.” BSP Circular No. 1166

For this thesis, transaction-specific funding is an architectural proposition to test. The analysis must consider cancellation, refunds, residual amounts, transferability, and repeated use, since those features may affect the practical character of the service. Calling an arrangement escrow does not itself establish that e-money rules are inapplicable.

4.5 Philippine Institutional Authority and Allocation of Roles

The General Banking Law provides a statutory basis for examining the powers and responsibilities of the institutions involved. Section 79 addresses authority to engage in trust business, while Section 80 addresses the administration of property under a trust entity’s custody. These provisions make the administering institution’s role a substantive research question. Republic Act No. 8791, Sections 79–80

The proposed architecture must distinguish the bank offering the product, any institution accepting the escrow appointment, the bank holding an underlying deposit, and the provider executing payment. Those roles may coincide, but the research should establish their allocation through the actual agreements and operating arrangements.

ODTI’s proposed role is software licensing and separately contracted implementation or support. The study must assess how the bank’s authority, operational control, and customer obligations remain explicit when technology and services are supplied by other parties.
MORB Section 413 identifies minimum written provisions for trust and fiduciary arrangements, including parties' capacities, funds or property, distribution, duties, liabilities, compensation, and termination. These requirements inform the proposed transaction terms and evidence of assent; the section does not independently establish that a particular digital agreement flow is sufficient. The institution's authority, electronic contracting process, and applicable customer-protection and financial-crime obligations require review. BSP MORB, Section 413

4.6 Comparative Experience

California demonstrates one approach to independent escrow businesses. Its Department of Financial Protection and Innovation administers an escrow licensing framework, while banks and certain other providers are addressed through applicable exemptions and other regulatory regimes. This illustrates differentiation among provider types rather than an absence of oversight. California DFPI, About the Escrow Law

United Kingdom guidance offers a separate comparison. The Solicitors Regulation Authority describes third-party managed accounts used for escrow payment services, while FCA guidance addresses safeguarding obligations for relevant payment institutions. These sources help distinguish contractual administration of a transaction from protections applying to customer funds held by payment providers. SRA, Third-Party Managed Accounts, FCA, Safeguarding Requirements

These examples provide comparative questions about custody, institutional authority, fund protection, and release control. They do not establish permission to operate an equivalent arrangement in the Philippines.

4.7 Existing Services and Access Models

Published service descriptions establish relevant precedents, not an uncontested market:

Sources: Chinabank escrow FAQ, ML ShopSafe, Dragonpay, 2019, Escrow.com overview, Trustap identity and users.

These materials were reviewed on 2026-11-03. They describe providers' own offerings; this study has not independently verified their licensing, service quality, adoption, or full contractual arrangements. Cross-jurisdictional comparisons do not establish Philippine permissions. Published fees, limits, and access requirements require confirmation before a competitive pricing or procurement decision.

4.8 Synthesis and Research Gap

The reviewed materials identify several ways institutions coordinate payment: administering entrusted property, executing customer instructions, or issuing undertakings governed by specified presentation requirements. The proposed digital escrow product must identify which relationship it creates and preserve that relationship throughout its technical lifecycle.

The research gap addressed by this thesis is specific to the proposed x-change model: whether its existing public issuance foundation can support bank-administered escrow for occasional users, combining transaction-specific funding, explicit release conditions, controlled party access, and traceable disposition without mandatory platform Account or wallet onboarding.

This is a proposed contribution to be evaluated. The present review does not establish that comparable products are absent, that the market is unserved, or that the legal characterization has been resolved. Further work must register source versions, check amendments, examine competing products, and connect the resulting findings to the proposed operating model.

5. Conceptual Framework

5.1 Unit of Analysis: The Funded Conditional Obligation

The central unit of this framework is a funded obligation governed by identifiable instructions and release conditions. Each obligation connects a funding principal, an intended recipient or recipient eligibility rule, an amount, an administering institution, and an authorized means of disposition.

Funding, issuance, release authorization, and settlement are distinct events. Funds may have been received while issuance remains incomplete. A Pay Code may have been issued while its release conditions remain unsatisfied. Payment may have been authorized while its execution remains pending or uncertain.

The framework preserves these distinctions so that a customer-facing status does not substitute for evidence of funding, authority, or completed settlement.

5.2 Actors and Institutional Roles

The funding principal supplies funds or authorizes the commitment of an existing position. Funding does not, by itself, determine the principal’s continuing right to cancel or recover the amount. Those rights must follow the governing arrangement.

The recipient is the person entitled to receive payment when the applicable conditions are satisfied. Recipient identification may occur at issuance or through a subsequently authorized process. Eligibility and identity must remain distinguishable: identifying a claimant does not necessarily establish entitlement.

The product-operating bank offers the service, establishes its terms, and governs its operation. Where it also accepts the escrow appointment, the agreement must identify its corresponding responsibilities. If another institution performs that role, the allocation must be explicit.

The settlement institution or provider executes the authorized movement of funds. It may be the product-operating bank or a separate institution. Its execution records supply evidence of payment outcomes within the agreed integration and reconciliation arrangements.

An authorized verifier or decision-maker, where required, establishes whether a release condition has been satisfied or resolves a disputed instruction. The agreement must define that party’s authority and the evidence on which it may act.

ODTI licenses x-change and supplies separately agreed services. Under this proposed model, a software license does not appoint ODTI as custodian, escrow agent, or decision-maker for customer transactions. Any additional operational role must be expressly identified and assessed.

5.3 Funding, Custody, and Treasury Attribution

The framework distinguishes three questions:

1. Where are the underlying funds held?
2. To whom are those funds attributable, and under what arrangement?
3. What amount is currently committed to a particular obligation?

A Treasury Position represents an internal attribution of value. A reservation records a restriction on its availability for competing uses. Neither record alone establishes ownership, a trust relationship, or protection against claims by third parties.

The bank’s account structure and agreements must explain the relationship between the underlying funds and the internal records. Reconciliation must preserve that relationship throughout funding, issuance, settlement, and any subsequent correction.

5.4 Public On-Demand Funding and Optional Client Funds

The primary model starts with a transaction, not a purchaser Account. The existing public issuance path is the foundation; its extension into the following escrow lifecycle remains proposed.

Public Pay and Issue. A purchaser accesses /x/auto-generate without platform login and funds a particular order for the full required amount, including applicable charges. The reviewed code binds institutional authority server-side and does not require the purchaser to hold Client Funds. For the proposed escrow product, the parties' agreed terms and the bank's acceptance must be linked to that order.

Optional existing Client Funds. An authenticated customer may instead authorize commitment of an available position. This alternative must preserve the same escrow rights and release controls, but its Account onboarding and residual-funds behavior must not be attributed to the public path.

The primary proposed sequence is:

Public access -> Transaction terms and institutional acceptance
              -> Specific full-amount funding order
              -> Verified payment and order-bound allocation
              -> Pay Code issued with continuing escrow commitment
              -> Conditions evaluated or dispute administered
              -> Authorized payment or refund
              -> Outcome recorded and reconciled

An issuance funding hold and a continuing escrow commitment serve different stages. Consuming the former to issue a voucher must not free the principal for unrelated use or permit immediate payout before escrow conditions are satisfied. The accounting transition must preserve backing without counting the same principal twice. This is an escrow-specific requirement to demonstrate, not a finding established by successful issuance.

Internal institutional accounts and ledger components remain necessary. Their use does not create a reusable wallet for the purchaser. The public checkout's late-payment, residual, failed-issuance, and refund rules must be evaluated separately from authenticated funding flows.

5.5 Pay Code and Release Authority

The Pay Code identifies or provides access to the associated settlement instruction. Its presentation allows the service to locate the obligation and begin the applicable claim and verification process.

Release authority depends on the governing conditions. These may include recipient identity, documentary evidence, approval by a designated party, a specified date, or another verifiable event. A deployment must state which conditions apply and how they are evaluated.

Identity checks, mobile verification, OTP, location, selfie, and signature may contribute evidence where appropriate. Their evidentiary purpose must be defined. For example, successful OTP verification may support control of a mobile number without establishing that goods were delivered.

Conditions and amendments must be versioned. A party must not be able to change the basis of an outstanding obligation merely by editing its current configuration.
Buyer acceptance, seller evidence, institutional holds, and dispute decisions require separate permissions. The proposed service must bind payout entitlement and destination to the agreed recipient and control destination changes. Guest-order possession must not become blanket authority to release, cancel, refund, or redirect funds.

5.6 Lifecycle and Exceptional Outcomes

The lifecycle should track funding, obligation status, and payment execution separately. An obligation can remain funded and reserved while a dispute is open or a provider outcome is uncertain.

A proposed normal lifecycle is:

Request -> Funding verified -> Funds committed -> Issued
        -> Conditions satisfied -> Release authorized
        -> Execution submitted -> Settlement confirmed -> Closed

Alternative outcomes require explicit treatment:

Expiry of a code must not be assumed to extinguish entitlement to the underlying funds. Likewise, a technical timeout must not be treated as proof that payment failed. The arrangement and authoritative evidence must determine the next action.

5.7 Traceability and Proposed Invariants

Each obligation should connect its governing agreement and instruction version to funding evidence, reservations, condition evaluations, approvals, execution attempts, final outcomes, and accounting entries.

The framework proposes the following invariants for subsequent evaluation:

1. The same committed amount cannot remain available for competing obligations.
2. Funding evidence cannot independently authorize release.
3. Presentation of a Pay Code cannot bypass its governing conditions.
4. A retry cannot create a second fulfillment of the same authorized obligation.
5. Uncertain execution cannot automatically release committed funds.
6. Every release, refund, or adjustment requires identifiable authority and evidence.
7. Fees and residual amounts have an explicit accounting and contractual disposition.
8. Every completed transaction can be reconstructed and reconciled.
9. Issuance preserves the continuing escrow commitment until an authorized disposition; it neither duplicates the reservation nor silently removes it.
10. A purchaser need not acquire a platform Account or reusable balance to complete the public product; guest recovery must preserve access to disputes and refunds.

These are proposed product requirements. Later sections must establish which are supported by existing capabilities and what evidence is needed to demonstrate them.

5.8 Boundary of the Framework

The framework describes a proposed bank-operated conditional settlement service. Its usefulness does not depend on assuming that every Pay Code is an escrow instrument.

The resulting agreements and operating arrangements may support an escrow characterization for particular products. Other products may create a different bank payment undertaking. The framework preserves the information needed to examine that distinction while providing a common architectural basis for funding, conditions, authority, execution, and evidence.

6. Hypotheses and Evaluation Criteria

6.1 Purpose of the Hypotheses

The proposed service combines several propositions: that customers need it, that x-change can support it, that banks can operate it reliably, and that its economics justify adoption. These propositions require different evidence and may produce different results.

The hypotheses below organize that evaluation. They are working propositions for an exploratory study. They do not represent established findings or statistical conclusions. Quantitative thresholds, sample sizes, and observation periods must be specified before collecting the evidence used to judge them.

6.2 H1: Customer Utility

Hypothesis. For selected transactions requiring delayed or conditional payment, eligible occasional users can obtain meaningful value from bank-operated escrow on demand through public, transaction-funded access without mandatory purchaser login, platform Account, or reusable spending balance.

Evaluation should compare the proposed experience with the alternatives customers actually use. Relevant measures include task completion, time and effort, total cost, understanding of release and refund rules, and willingness to use the service for another transaction.
Recruitment should include nonusers of existing escrow services and investigate their reasons for nonuse. Evaluation should distinguish additional transactions enabled by reduced access barriers from substitution between existing services. Guest entry alone is not evidence of customer value or market creation.

Support would require evidence that a defined customer group experiences a material improvement against a specified alternative. The proposition would require revision if customers cannot understand the arrangement, find the conditions burdensome, or obtain equivalent benefits more conveniently elsewhere.

Access without a reusable spending balance must be evaluated separately from access without registration, identification, or an existing bank relationship. Those are distinct product features.

6.3 H2: Architectural Fit

Hypothesis. The documented x-change architecture provides a reusable foundation for the proposed service, with identifiable and bounded extensions.

Evaluation should map each product requirement to documented design, implementation evidence, and demonstrated behavior. The mapping must distinguish existing capabilities, configurable capabilities, required extensions, and unresolved design questions.

Support would require a coherent implementation path that preserves the distinction among funding, reservation, release authority, execution, and settlement. The proposition would be weakened if essential requirements depend on extensive manual reconstruction or changes that contradict the existing architecture.

The presence of similarly named components is insufficient evidence. A reservation component, for example, must be evaluated against the specific concurrency, release, and recovery requirements of the proposed product.

6.4 H3: Operational Integrity

Hypothesis. Within a defined operating scope, the proposed controls can preserve attributable funding, prevent unauthorized or duplicate fulfillment, and maintain reconcilable records through normal and adverse transaction scenarios.

Evaluation should include concurrent claims, repeated requests, duplicate funding notifications, provider timeouts, delayed confirmations, definitive failures, disputes, cancellations, expiry, and recovery after interruption.

For the evaluated scenarios, acceptance requires no unexplained duplicate settlement, unauthorized release, or reuse of committed funds. Every tested obligation must remain attributable and reconstructable, including those left unresolved.

An observed control failure would contradict the relevant control proposition for that version and scope. Conversely, successful testing would provide bounded evidence; it would not establish that fraud or failure is impossible.

6.5 H4: Bank Operability

Hypothesis. A participating bank can govern the service through explicit roles, controlled access, documented procedures, and sufficient operational evidence while retaining ownership of its customer obligations.

Evaluation should examine issuance approval, release decisions, disputes, refunds, reconciliation, incident response, and continuity. Bank personnel should be able to explain and perform the evaluated procedures using the agreed tools and documentation.

Support would require clear decision authority and demonstrated handling of representative cases. The proposition would require revision if routine operation depends on undocumented intervention by individual developers or if responsibility for unresolved transactions cannot be assigned.

This hypothesis concerns operational capability. Institutional authority remains a separate question.

6.6 H5: Commercial Feasibility

Hypothesis. For a defined customer segment and transaction profile, the service can deliver customer value at a price that covers its attributable operating costs and supports sustainable bank operation.

Evaluation should account for payment-provider charges, infrastructure, licensing, customer support, identity verification where applicable, reconciliation, disputes, fraud losses, and exception handling.

Support would require a credible contribution margin under stated volume and usage assumptions. Sensitivity analysis should examine lower adoption, higher support demand, longer holding periods, and more frequent disputes.

The proposition would be weakened if viability depends on unsupported transaction forecasts, unpriced manual work, or income from held funds that the proposed arrangement does not permit.

6.7 Legal and Institutional Questions

Legal characterization will be evaluated through reasoned analysis of the actual agreements, institutional roles, and applicable authorities. It will not be treated as a statistical hypothesis or inferred from technical success.

The review must address whether the proposed arrangement constitutes escrow, another payment undertaking, or overlapping activities; which institution may perform each role; and what customer rights follow.

A finding that a particular structure is unsuitable would require revision of that structure. It would not necessarily invalidate the broader customer need or the usefulness of the settlement architecture.

6.8 Evaluation Design and Decision Rules

Before empirical evaluation begins, the study should specify:

1. The product version, institution, customer segment, and transaction scenarios under evaluation.
2. The comparison service or existing customer practice.
3. Measures, acceptance thresholds, sample selection, and observation period.
4. Evidence sources and responsibility for recording outcomes.
5. Treatment of failed, abandoned, disputed, and unresolved transactions.
6. Conditions requiring suspension, redesign, or further investigation.

Results should be reported as supported within the evaluated scope, contradicted, or unresolved. Missing evidence must remain visible. Acceptance thresholds should not be changed after observing results without documenting the change and its implications.

6.9 Relationship Among Findings

The hypotheses form a cumulative assessment rather than a single pass-or-fail score. Customer demand may exist while the implementation remains incomplete. A technically sound system may prove commercially unattractive. A viable product may require a different institutional arrangement from the one initially proposed.

The study should preserve these distinctions so that each finding leads to an identifiable decision: continue, refine, narrow the scope, change the operating model, or discontinue a particular proposition.

7. Assumptions and Scope

7.1 Status of the Assumptions

The study uses a defined operating model to make the proposed service examinable. Its assumptions identify the conditions under which the architecture and hypotheses will be evaluated. They are not findings.

Each material assumption should eventually be linked to supporting evidence, an accountable reviewer, or a question requiring resolution. If an assumption changes, the study must identify the affected requirements, analyses, and conclusions.

7.2 Bank Ownership and Operation

The proposed product is offered and governed by a participating bank. The bank establishes its customer agreements, approves product rules, controls operational authority, and administers the obligations allocated to it.

ODTI licenses x-change and supplies separately agreed implementation, maintenance, training, or support. The model assumes that these services can be provided while preserving the bank’s control over financial decisions and production access.

Bank ownership concerns substantive responsibility and control. Hosting location, branding, and possession of source code may support that control, but do not individually establish it.

7.3 Institutional Authority and Legal Arrangement

The study does not assume that a bank’s existing permissions necessarily cover every proposed feature. The institution’s authority must be evaluated against the actual custody, agency, payment, and other roles contemplated.

The term digital escrow remains a working product description. Its suitability depends on the resulting agreements and operation. Alternative characterizations remain open where the evidence supports them.

No assumption is made that the service falls outside e-money or other applicable frameworks merely because customers do not maintain a reusable spending balance.

7.4 Customers and Access

The intended service is publicly accessible to eligible individuals and businesses, including purchasers without an existing platform Account. The recommended initial evaluation concerns occasional domestic PHP purchases of specified physical goods, not unrestricted acceptance of every customer or transaction.

Public access, customer eligibility, identification, action authentication, and a reusable wallet relationship are distinct concerns. The primary model does not require a purchaser login or platform spending balance. It does require the bank to define identification, screening, agreement, and authorization procedures. A lack of platform login does not establish permission to serve a non-depositor under every institutional arrangement.

Secure transaction links and step-up verification may support participation without conventional account credentials. Their use for agreement, acceptance, disputes, refunds, and recovery is a proposed escrow access design requiring validation. A lost browser session must not erase rights or make recourse depend on opening a wallet.

The initial evaluation should identify a specific customer segment and transaction purpose. Findings from that scope should not automatically be generalized to all retail, commercial, or public-sector payments.

7.5 Funding and Availability

The primary model concerns full-amount external funding attributable to a particular public issuance order. Existing Client Funds are an optional alternative, not a prerequisite.

The service must establish when funding is sufficiently verified to support issuance and subsequent release. An incoming notification or customer-provided receipt does not, by itself, establish that standard.

Committed amounts must remain distinguishable from available amounts. Fees, excess receipts, unmatched funding, and residual amounts require explicit treatment.

The reviewed public issuance code already supports funding without a purchaser Account or reusable balance. Preservation of that experience across the proposed escrow lifecycle, including exceptional dispositions, remains subject to evaluation. Offering stored-value or reusable-balance variants elsewhere in the platform does not bring those variants into this product's initial scope.

7.6 Custody and Settlement Infrastructure

The operating bank may use its own account and payment infrastructure or an agreed arrangement with a separate settlement institution.

The study does not assume that NetBank or another named provider offers every account structure, escrow appointment, or operational capability required. Those capabilities must be confirmed for the proposed arrangement.

Internal Treasury attribution must remain distinguishable from the underlying custody structure. The framework does not presume that a reservation creates a separate bank account or legally segregated property.

7.7 Release Conditions and Online Settlement

Each obligation must have identifiable release conditions and an authorized process for evaluating them. Conditions may range from recipient verification to documentary presentation or approval by a designated party.

The study does not assume that software can independently establish every real-world fact. Where human judgment or external evidence is necessary, the responsible party and decision process must be specified.

Pay Codes may be communicated or presented through channels that do not themselves require connectivity. Authorization and settlement, however, require online validation against the authoritative operating system and applicable provider evidence.

7.8 Exceptions and Continuing Obligations

The evaluated scope includes cancellation, expiry, disputes, failed execution, uncertain execution, refunds, and reconciliation exceptions.

A change in technical status must not silently determine a party’s rights. Code expiry, for example, requires an explicit rule for the continuing obligation and disposition of funds.

The study assumes that unresolved transactions remain visible and attributable until an authorized disposition is recorded. Manual intervention, where necessary, must preserve evidence and accountability.

7.9 Initial Exclusions

The initial product thesis does not evaluate:

1. Lending, credit underwriting, or advances against expected escrow proceeds.
2. Investment management or a business model dependent on returns from held funds.
3. Cross-border payments, foreign exchange, or multiple currencies.
4. Negotiability, unrestricted transfer, or secondary trading of Pay Codes.
5. Offline authorization or offline settlement.
6. Universal support for every bank, payment provider, or transaction type.

These exclusions define the first research scope. A later extension requires its own assumptions, institutional assessment, and evaluation criteria.

7.10 Evidence and Generalization

The initial paper is a product and architecture thesis. Documentary sources, demonstrations, interviews, and pilot observations provide different kinds of evidence and must be reported accordingly.

Prototype success does not establish production reliability. A bounded pilot does not establish suitability at unrestricted scale. Founder accounts explain the origin and intended direction of the system but do not independently verify its effectiveness.

Conclusions must identify the product version, institutional arrangement, transaction scope, and evidence on which they depend.

8. Methodology

8.1 Research Design

The study will use an exploratory design combining documentary research, architecture analysis, transaction scenarios, stakeholder inquiry, and a proposed controlled pilot.

The unit of analysis is the funded conditional obligation described in Section 5. Evaluation will examine how that obligation is created, funded, governed, fulfilled, or otherwise resolved.

The methods address different questions. Documentary research examines institutional roles and applicable authorities. Architecture analysis evaluates implementation feasibility. Stakeholder inquiry examines customer utility and bank operability. A controlled pilot, if authorized, would provide bounded operational and commercial evidence.

8.2 Documentary Research

Sources will be selected for their relevance to the proposed arrangement and evaluated under the package’s Source Evaluation Protocol and Research Workflow.

The review will prioritize statutes, official regulatory issuances, judicial decisions, and authoritative instrument rules. Institutional product materials and scholarly or professional commentary may supply context, with their evidentiary limits identified.

Each material source should record its issuer, publication date, version, relevant provision, applicability, subsequent amendments, and retrieval date. Historical materials may explain development but must not automatically be treated as current authority.

The analysis will preserve competing interpretations and distinguish an express requirement from an inference. A source’s general relevance does not establish its application to a particular bank or deployment.

8.3 Architecture and Requirements Mapping

The study will establish a versioned baseline of x-change documentation and relevant implementation evidence.

Each product requirement will be mapped to its supporting design, implementation component, available evidence, and remaining gap. Capability status will distinguish:

1. Proposed.
2. Documented.
3. Implemented with supporting evidence.
4. Demonstrated under specified conditions.
5. Observed in an authorized operating environment.

These statuses describe different levels of support. They must not be collapsed into a general claim that the product is ready.

The mapping will connect business requirements, legal questions or applicable authorities, proposed invariants, software components, and evaluation evidence. Where a relationship remains unresolved, that gap will remain explicit.

8.4 Transaction Scenario Analysis

Scenarios will examine both funding paths and the lifecycle defined in Section 5.
The public on-demand path is the primary acceptance scope; the optional Client Funds path must be reported separately. Tests must cover continuity of backing between issuance funding and escrow commitment, distinct buyer and seller permissions, and guest recovery after session loss.

For each scenario, the study will specify the initial state, actors, governing instruction, funding evidence, release conditions, permitted actions, expected outcome, and accounting consequences.

Normal scenarios will be supplemented by adverse and boundary cases, including duplicate requests, simultaneous claims, unmatched funding, cancellation, expiry, disputes, interrupted processing, delayed provider confirmation, and uncertain execution.

Scenario walkthroughs will identify design problems. Executed tests or demonstrations, when separately undertaken, will provide evidence of behavior for the evaluated version and environment. A walkthrough alone will not be reported as a successful execution.

8.5 Stakeholder Inquiry

Customer inquiry will investigate existing practices, transaction difficulties, understanding of the proposed service, acceptable costs, and willingness to adopt. It should include people who currently avoid escrow because of setup, account, wallet, membership, or marketplace requirements, and test whether the proposed service actually removes their barriers.

Bank inquiry will examine product ownership, operational roles, integration constraints, approval processes, reconciliation, support, and exception handling. External counsel will assess the proposed agreements, characterizations, and institutional questions within an agreed review scope.

Participant selection, interview questions, and analysis methods will be documented before formal inquiry. Early exploratory conversations may inform the design but will be distinguished from systematically collected findings.

The study will record disagreement and negative feedback alongside favorable responses.

8.6 Controlled Pilot Proposal

A pilot would proceed only under the participating institution’s applicable authorization and approval arrangements. This paper does not authorize live transactions.

The proposal will define the institution, customer segment, permitted use cases, software version, transaction limits, release conditions, operating period, and responsible personnel.

It will also specify monitoring, reconciliation, support, incident handling, suspension criteria, and the disposition of outstanding obligations when the pilot ends.

Pilot evidence should include successful, failed, abandoned, disputed, and unresolved cases. Reporting only completed payments would provide an incomplete account of performance.

8.7 Measures and Analysis

Measures will be selected against the hypotheses in Section 6.

Definitions, denominators, observation windows, and acceptance thresholds must be established before the corresponding evaluation.

Initial analysis may be descriptive. Any statistical inference will require an appropriate sampling design and sufficient data. The study will not infer broad effectiveness from a small convenience sample or a limited number of successful transactions.

Commercial analysis will include sensitivity to adoption, transaction size, holding period, support demand, and disputes.

8.8 Evidence Management and Research Integrity

Every material finding should be traceable to its source, observation, interview record, or executed evaluation.

Records will identify the relevant product version, environment, date, method, and limitations. Sensitive customer information, credentials, and unnecessary personal data should be excluded from the research record or handled through an appropriate controlled process.

Founder involvement and ODTI’s commercial interest will be disclosed. Independent review should be sought where practical, and reviewers’ scope and relationship to the project should be recorded.

AI may assist with source discovery, organization, comparison, and drafting. AI-generated statements will not be treated as authorities or observations. Sources and material interpretations require accountable human review.

8.9 Synthesis and Revision

Findings will be assessed against the research questions and hypothesis criteria.

Each proposition will be reported as supported within a defined scope, contradicted, or unresolved. Discrepancies between documentary analysis, observed behavior, and stakeholder expectations will be examined rather than averaged away.

Changes to assumptions, requirements, or evaluation criteria will be recorded with their reasons. Material changes may require renewed evaluation before earlier evidence can support the revised model.

The resulting research record should explain both the proposed product and how the evidence changed its design.

9. Documented Observations

9.1 Status of the Observation Record

The present observation record consists of selected published sources, package documentation, and inspection of the public issuance source and test definitions. The source baseline is recorded in Section 13.6. No tests or deployed endpoint were exercised for this revision; documentation's reported acceptance runs are not new observations by this study. The record is preliminary and does not constitute a complete authority review, implementation audit, or empirical evaluation.

No structured customer study, independent bank assessment, or controlled digital escrow pilot is reported here. The hypotheses in Section 6 therefore remain unresolved.

9.2 Conceptual Origin

Hurtado’s monographs describe the development of x-change around financial obligations, configurable conditions, supporting evidence, and eventual settlement. They provide a documented account of the founder’s reasoning and intended architecture. Hurtado, When Money Adapts to People, Hurtado, x-change: A Founder’s Update

These accounts support the observation that conditional settlement is consistent with the project’s stated direction. They do not independently establish customer demand, operational effectiveness, or suitability for a bank escrow product.

9.3 Escrow in the Reviewed BSP Material

BSP Circular No. 609 expressly describes escrow within its reporting framework for trust institutions. The definition connects an agency agreement, property deposited by a principal, an administering trust institution, and delivery contingent on an event or action. BSP Circular No. 609

This establishes that escrow is an expressly recognized category in the reviewed BSP material. It does not resolve the proposed product’s classification, the authority of a particular institution, or the current applicability of every provision. Those questions require further source and arrangement-specific review.

9.4 Separation of Treasury Facts

The reviewed x-change document, docs/architecture/TREASURY_INITIAL_STATE_AND_ACCOUNT_PORTFOLIOS.md, distinguishes Provider Inventory, Treasury Positions, and Pay Code obligations.

Provider Inventory concerns value observed at a settlement resource. Treasury Positions concern internal attribution. Pay Code obligations concern outstanding instructions and their effect on issuance capacity.

This documented separation is relevant to the proposed service because custody evidence, attribution, and commitment must remain distinguishable. It does not establish legal segregation or prove that a complete escrow accounting model has been implemented.

9.5 Documented Control Mechanisms

The reviewed Treasury and claim-outcome documents describe mechanisms relevant to attributable funding and controlled fulfillment. These include verified funding, reservations, operation references, uniqueness constraints, restricted claim outcomes, and maker-checker procedures for particular workflows.

The observation is limited to the documented mechanisms and their stated scope. A control described for one funding or claim path cannot automatically be assumed to apply to every proposed escrow transaction.

A versioned requirements map and supporting implementation evidence remain necessary before these mechanisms can support findings under the architectural-fit and operational-integrity hypotheses.

Inspection of the public issuance path establishes a more specific foundation:

The public and authenticated on-demand paths must not be conflated. The authenticated funding compass describes some late payments becoming Client Funds. Public checkout documentation instead describes its own recovery and manual-refund cases, while public issuance documentation identifies residual-disposition and promotion gates. These are distinct exception policies, not proof that the public purchaser must fund a wallet. Exact release and host evidence must be checked before a bank readiness claim.

9.6 Distinction Between Payment Evidence and Release Authority

The proposed framework requires separate evidence of funding, satisfaction of release conditions, authorization, and execution outcome.

The reviewed documentation provides relevant concepts for funding verification and settlement evidence. However, this thesis has not yet established a complete mapping from an escrow agreement’s conditions to authorized decision-makers, evidence requirements, disputes, amendments, and final disposition.

That mapping remains a product-design and evaluation task. Its absence from the current research record should not be treated as proof that no related functionality exists elsewhere in the package.

9.7 Institutional Operating Model

The operating model adopted for this thesis assigns product ownership and operation to a participating bank, with ODTI licensing x-change and supplying separately agreed services.

This is a proposed allocation of responsibilities. The present record does not include an executed bank product agreement, escrow appointment, confirmed custody arrangement, or institution-specific authority assessment for this product.

Similarly, identifying NetBank or another institution as a possible settlement provider does not establish its acceptance of the proposed role.

9.8 Evidence Still Required

The following evidence has not yet been established within this study:

9.9 Preliminary Implication

The reviewed materials establish an existing account-free issuance entry point and relevant architectural mechanisms for investigating its escrow extension. Published competitor materials establish precedents for escrow, transaction funding, and guest-buyer access. Together they support a specific access-and-administration hypothesis, not a claim of invention or an uncontested market.

They do not yet demonstrate a complete bank-operated digital escrow product. Subsequent analysis must explain how the existing foundations would satisfy the proposed requirements, where extensions are necessary, and what evidence could change that assessment.

10. Analysis and Discussion

10.1 The Product Opportunity

The proposed service addresses the interval between committing funds and becoming entitled to receive them. During that interval, the parties need a dependable account of the amount committed, the applicable conditions, who may authorize release, and what happens if the transaction cannot proceed.

This suggests a product opportunity beyond transfer speed. A bank could offer customers a governed means of committing funds to a specific purpose while preserving an understandable route to payment, refund, or dispute resolution.

The opportunity remains a hypothesis. Its significance depends on whether selected customers experience these problems frequently enough, and whether the proposed service improves their existing practices at an acceptable cost.

10.2 Two Candidate Institutional Relationships

The conceptual framework exposes two relationships that require separate examination.

Under an escrow agency arrangement, the institution administers entrusted funds according to agreed conditions. Analysis must establish the parties’ entitlements and the agent’s authority throughout the transaction.

Under a bank payment undertaking, the bank assumes a defined obligation to pay an eligible recipient upon the stipulated presentation or conditions. Analysis must establish the content of that undertaking and the rights of the purchaser and recipient.

Similar customer interfaces could support either arrangement. Receiving funds, issuing a code, and making a later payment do not alone distinguish them. The agreements, accounting treatment, and actual conduct must explain the relationship.

The product should therefore be designed around an explicit institutional promise before its name is finalized.

10.3 From Public Issuance to Continuing Escrow

The existing public Pay and Issue path makes the transaction the purchaser's starting point. The proposed escrow service must add a continuing institutional relationship: agreed rights, a funded commitment visible to both parties, restricted release authority, and an authorized route through disputes, payment, or refund.

Verified funding authorizes neither acceptance of the goods nor unconditional seller payout. A seller's identity check cannot substitute for the buyer's acceptance. Once rights have arisen under the agreement, the buyer cannot recover the principal merely by cancelling a browser order unless the arrangement permits that disposition.

Preserving that experience requires attention to exceptions. Excess payments, unsuccessful issuance, cancellation, and expired claim windows can leave amounts awaiting disposition. If those amounts become freely reusable for unrelated transactions, the resulting experience would differ from the transaction-specific model initially proposed.

The design must therefore specify how every residual entitlement is recorded and resolved. Avoiding a customer-facing balance does not eliminate the need for internal accounting or a record of amounts owed.

10.4 Architecture as an Expression of the Agreement

The documented distinction among Provider Inventory, Treasury Positions, and Pay Code obligations provides a useful starting point for representing custody evidence, attribution, and commitment separately.

The proposed escrow product requires an additional connection: each permitted action must follow from the governing agreement and an identifiable grant of authority.

A release rule should establish what condition is being evaluated, what evidence is acceptable, who may decide, and which version governs the obligation. Software may automate that rule where its inputs are sufficiently reliable. Where judgment is necessary, the system must preserve the authorized decision and its basis.

A successful identity check, for example, may identify a claimant without establishing contractual performance. The architecture must preserve the purpose and limits of each piece of evidence.

10.5 Failure Handling as a Core Product Requirement

The value of conditional settlement becomes especially visible when a transaction does not follow its expected path.

An uncertain payment outcome creates a risk of paying twice if a retry occurs prematurely. A dispute creates a need to preserve funds while determining authority. Expiry creates a question about continuing entitlement. Cancellation may involve competing rights once the recipient has relied on the arrangement.

These cases require defined states, accountable decisions, and reconcilable accounting consequences. Manual review may form part of the service, provided its authority, evidence, and cost remain explicit.

The proposed product should be evaluated through these cases as seriously as through successful redemption.

10.6 Bank Ownership and Vendor Dependence

Bank ownership of the product can align the customer relationship, financial obligations, and operational authority within an identifiable institution.

That ownership must be supported by practical capability. The bank needs sufficient access, procedures, training, contractual rights, and continuity arrangements to operate the service and resolve outstanding obligations.

ODTI may supply substantial technical expertise while the bank retains financial decision authority. The boundary becomes unclear if routine settlement or exception resolution depends on undocumented developer intervention.

Bank operability must therefore be demonstrated through actual staff tasks and recovery exercises within the evaluated scope.

10.7 Market Positioning and Commercial Feasibility

The proposed positioning is escrow on demand, not a newly invented digital check or a proven blue ocean. The intended noncustomer is a person or small business needing protection for an occasional transaction but unwilling to establish another wallet, marketplace membership, or bespoke bank arrangement.

The market-creation hypothesis is that standardized bank-administered terms and public transaction funding can lower the total effort and cost of obtaining appropriate protection. Section 4.7 establishes that escrow, externally arranged purchases, and guest-buyer access already have precedents. The proposed combination must earn its differentiation through measured outcomes.

These objectives are not all demonstrated capabilities. Reduced documentation means standardization and removal of unnecessary repetition, not omission of required customer or contractual evidence.

For banks, the proposition is standardized digital administration of eligible escrow transactions. For fintech distributors, it is integration of that bank service into an existing journey without silently making the distributor custodian or release decision-maker. API access does not transfer financial authority.

A viable price must cover more than execution charges. Identity checks, customer support, disputes, reconciliation, investigation, and recovery may determine the economics. Greater flexibility can increase customer value while also increasing operating complexity.
Unit economics should separately identify provider and payout fees, verification costs, support effort, expected dispute-handling cost, fraud and operational losses, infrastructure, and licensing. Adoption and willingness to pay must be evaluated against these costs rather than presumed from the simplicity of guest entry.

The first product should therefore concentrate on a use case with understandable conditions and measurable benefits. Broader functionality should follow evidence of demand and operability.

10.8 Implications for x-legal

The thesis identifies candidate additions to the legal knowledge system: a clearer distinction between reservation and escrow, a model of release authority, and a record of how entitlement changes throughout an obligation’s lifecycle.

These concepts should enter canonical grammar or architectural invariants only through the package’s review process. A product proposal must not silently become a settled legal position.

Traceability should connect each material product requirement to the relevant agreement provision or authority, its architectural expression, the implementing component, and evaluation evidence. Unresolved relationships should remain visible.

10.9 Current Assessment of the Hypotheses

The present record supports continued investigation but does not resolve the five hypotheses.

The immediate contribution is a defined model and a research agenda. The next stage should narrow the initial use case, specify the bank’s promise, and assemble the evidence needed to evaluate that model.

11. Limitations and Validation Plan

11.1 Present Limits of the Study

This paper currently presents a product concept, an architectural framework, and a proposed evaluation method. Its evidence consists of selected published sources and package documentation.

It does not report a completed legal review, comprehensive market survey, independent implementation assessment, or controlled digital escrow pilot. The five hypotheses remain unresolved.

The literature review also requires further development. Sources must be registered with their versions, relevant provisions, amendment history, and applicability. The comparative examples illustrate selected arrangements rather than a representative survey of international practice.

11.2 Researcher Involvement and Potential Bias

The product originates in the founder’s research and is associated with a proposed commercial licensing model. That involvement provides architectural knowledge while creating a potential preference for interpretations favorable to the product.

The study should address this through explicit assumptions, preserved adverse arguments, independent review where practical, and reporting of unsuccessful outcomes. Customer and bank inquiry should allow participants to reject the proposed solution or identify better alternatives.

AI-assisted research and drafting introduce an additional need to verify sources, distinguish inference from authority, and retain accountable human judgment.

11.3 Validation Stage One: Define the Initial Product

The first stage should select one customer segment and a limited set of transaction scenarios.

Its principal output should be a product specification stating the bank’s promise, the parties’ rights, funding arrangements, release conditions, cancellation rules, dispute process, and disposition of unresolved funds.

The specification should identify which features are essential and which may be deferred. Ambiguity about entitlement or release authority should remain an open issue until resolved.

11.4 Validation Stage Two: Assess the Institutional Arrangement

The participating bank and external counsel should examine the proposed agreements, institutional roles, account structure, and relevant authorities.

The review should distinguish established requirements, reasoned interpretations, unresolved questions, and matters requiring regulatory engagement. Any dependence on a separate settlement bank, escrow institution, or service provider should be confirmed through the appropriate arrangements.

The output should be a documented assessment with a defined scope and remaining conditions. It should not be represented as a general endorsement of x-change or all future products built with it.

11.5 Validation Stage Three: Establish Architectural Coverage

A versioned requirements map should connect the product specification to documented design, implementation components, evaluation scenarios, and evidence.

Particular attention should be given to transaction-specific attribution, reservation integrity, condition evaluation, approval authority, uncertain execution, refunds, and reconciliation.

The output should identify supported requirements, necessary extensions, and unresolved dependencies. Documented intentions must remain distinguishable from demonstrated behavior.

11.6 Validation Stage Four: Evaluate Operation and Customer Understanding

Controlled evaluations should examine customer comprehension and bank staff operation before a live pilot is considered.

Customers should be able to understand when funds are committed, what permits release, whether cancellation is possible, and how disputes or refunds are handled.

Bank personnel should demonstrate representative issuance, review, settlement, exception, reconciliation, and recovery tasks. Observations should record manual effort, escalation, errors, and dependence on specialist intervention.

Acceptance thresholds and stopping conditions should be defined before the evaluation.

11.7 Validation Stage Five: Conduct a Bounded Pilot

If the preceding assessments support proceeding and the applicable institutional arrangements are in place, a controlled pilot may evaluate actual customer behavior, operating performance, and costs.

The pilot should have explicit transaction and participation limits, monitoring responsibilities, reconciliation frequency, incident procedures, and an orderly exit plan.

All transaction outcomes should enter the evidence record. Outstanding obligations must remain attributable and subject to an authorized disposition when participation or the pilot ends.

Pilot success would support conclusions only within the evaluated scope.

11.8 Revision and Suspension Criteria

The proposed model should be revised or its evaluation suspended when evidence reveals a material unresolved issue, including:

1. Unclear entitlement to funds or conflicting release authority.
2. Unauthorized or duplicate fulfillment.
3. Unexplained funding or reconciliation differences.
4. Inability to establish whether execution occurred.
5. Customer misunderstanding that materially affects informed use.
6. Operational dependence that prevents the bank from controlling the service.
7. An institutional or legal question that prevents the proposed activity.
8. Costs or demand inconsistent with the commercial hypothesis.

Each finding should identify the affected version, obligation, or hypothesis. The response may be a correction, narrower scope, alternative arrangement, further investigation, or discontinuation.

11.9 Conditions for Stronger Conclusions

Stronger conclusions require convergence among legal analysis, demonstrated behavior, customer evidence, bank operability, and commercial results.

A favorable result in one area cannot substitute for missing evidence in another. The research record should explain the scope of each conclusion, the evidence supporting it, and the conditions under which it may cease to hold.

The validation plan therefore provides a route from a promising concept to an examinable bank product while preserving the possibility that the evidence will require a different design.

12. Conclusion

12.1 The Proposed Contribution

This paper develops a product and architecture thesis for a bank-operated digital escrow service powered by x-change. Its starting point is the separation between creating a financial instruction and completing its settlement.

The proposed service extends that separation into an explicit lifecycle: funds are received or committed, conditions govern release, authorized parties make decisions, and execution produces evidence that can be reconciled. The Pay Code identifies or provides access to the associated instruction within that lifecycle.

The contribution at this stage is a defined model and a method for evaluating it. The paper provides a basis for bank assessment, further architecture work, legal analysis, customer inquiry, and controlled operational evaluation.

12.2 Answer to the Central Research Question

The central question remains open: can the existing public issuance model deliver useful bank-operated escrow without requiring a purchaser login, platform Account, or reusable spending balance?

The account-free funding entry point is not merely hypothetical: inspected x-change code supports public, full-amount issuance orders without purchaser login or reusable wallet funding. The unresolved question is whether the additional agreement, continuing commitment, party-specific authority, dispute, and disposition controls can deliver useful bank-operated escrow. A complete assessment still requires product-specific requirements mapping, executed evidence, reviewed institutional arrangements, and customer and commercial evaluation.

The present record supports continued investigation. It does not establish a completed or production-ready digital escrow product.

12.3 Disposition of the Hypotheses

All five hypotheses remain unresolved.

Customer utility requires evidence from defined users and comparison with their existing practices. Architectural fit requires a versioned mapping from product requirements to demonstrated capabilities. Operational integrity requires evaluated normal and adverse scenarios. Bank operability requires institution-specific procedures and staff evidence. Commercial feasibility requires credible demand, pricing, and cost analysis.

Legal characterization remains a separate analytical question. The agreements and actual operation must establish whether a particular offering constitutes escrow, another bank payment undertaking, or overlapping activities.

12.4 Implications for Product Development

The next product decision is to select an initial use case and state the bank’s promise precisely. That promise should explain who is entitled to the funds, what authorizes payment, who may cancel or dispute the instruction, and how unresolved amounts are disposed of.

The resulting specification should guide the architecture, customer experience, account structure, and institutional review. It should also determine whether digital escrow accurately describes the proposed service.

A narrow initial scope would make the product easier to examine and its results easier to interpret. Expansion should follow evidence that the institution can explain, operate, and sustain the service.
The recommended direction is escrow on demand for eligible everyday transactions, beginning with the bounded goods-purchase candidate. Market creation remains a hypothesis to evaluate against existing bank, wallet-based, and guest-access services; it is not a conclusion established by this paper.

12.5 Closing Perspective

The thesis carries forward the monographs’ proposition that financial infrastructure should accommodate the circumstances in which people transact. Timing, distance, evidence, and trust continue to shape those circumstances even when transfers are fast.

A bank-operated digital escrow product could address them by making commitments, conditions, and settlement more accessible and understandable. Whether the proposed model achieves that purpose must be determined through the research and validation process set out in this paper.

13. References

13.1 Status of the Bibliography

This bibliography identifies sources cited in the initial draft and package materials informing its architecture discussion. Inclusion does not establish that an authority remains unamended or applies to a particular institution.

A subsequent source-registration pass must record relevant provisions, publication and revision details, retrieval dates, and applicability. Package evidence must also be pinned to identifiable versions.

13.2 Foundational Monographs

Hurtado, L. B. (2026, June). When Money Adapts to People: A Founder’s Discovery Thesis on the Future of Financial Settlement. The x-change Monographs, Volume II. 3neti.
https://3neti.com/insights/when-money-adapts-to-people

Hurtado, L. B. (2026, June). x-change: A Founder’s Update. The x-change Monographs, Volume I. 3neti.
https://3neti.com/insights/x-change-a-founders-update

These founder-authored sources establish the conceptual origin and intended direction of the project. They are not independent evaluations of its effectiveness.

13.3 Philippine Primary Authorities

Bangko Sentral ng Pilipinas. (2008, May 26). Circular No. 609: Financial Reporting Package for Trust Institutions.
https://www.bsp.gov.ph/Regulations/Issuances/2008/c609.pdf

Relevant material includes the definition of escrow under item (6). Subsequent amendments and current applicability require registration and review.

Bangko Sentral ng Pilipinas. (2023, February 7). Circular No. 1166: Amendments to the Regulations on Electronic Money (E-Money) and the Operations of Electronic Money Issuers (EMI) in the Philippines.
https://www.bsp.gov.ph/Regulations/Published%20Issuances/Images/Circular_1166.pdf

Relevant material includes the characteristics defining e-money. Subsequent amendments and applicability to the proposed arrangement require review.

Republic of the Philippines. (2000, May 23). Republic Act No. 8791: The General Banking Law of 2000. Supreme Court E-Library.
https://elibrary.judiciary.gov.ph/thebookshelf/showdocs/2/5339

Relevant material includes institutional powers and Sections 79–80 on trust operations. These references do not constitute an institution-specific authority assessment.

Philippine Legislature. (1911). Act No. 2031: The Negotiable Instruments Law. Supreme Court E-Library. Sections 1, 4, and 185 inform the limits of the check analogy. Reviewed 2026-11-03.
https://elibrary.judiciary.gov.ph/thebookshelf/showdocs/28/26194

Bangko Sentral ng Pilipinas. MORB Section 413: Trust and Other Fiduciary Business. Online text reviewed 2026-11-03.
https://morb.bsp.gov.ph/413-trust-and-other-fiduciary-business/

The BSP regulations index lists a MORB edition updated through December 2025. The final legal analysis must reconcile the cited online and historical provisions with that edition and subsequent issuances; this revision is not a completed amendment or applicability review.
https://www.bsp.gov.ph/SitePages/Regulations/RegulationsList.aspx

13.4 Comparative Regulatory and Institutional Sources

California Department of Financial Protection and Innovation. About the Escrow Law. Publication and revision dates to be registered.
https://dfpi.ca.gov/regulated-industries/escrow-law/about-the-escrow-law/

Financial Conduct Authority. Safeguarding Requirements for Payment Institutions and Electronic Money Institutions. Publication and revision dates to be registered.
https://www.fca.org.uk/firms/emi-payment-institutions-safeguarding-requirements

Solicitors Regulation Authority. Third-Party Managed Accounts. Publication and revision dates to be registered.
https://www.sra.org.uk/solicitors/guidance/third-party-managed-accounts/

These sources support selected jurisdictional comparisons. They do not establish Philippine permissions or equivalent legal treatment.

13.5 Trade Finance Explanatory Sources

International Trade Administration. Letters of Credit and Documentary Collection. Publication and revision dates to be registered.
https://legacy.export.gov/article2?id=Letters-of-Credit-and-Documentary-Collection

ICC Academy. Understanding Demand Guarantees: A Guide to URDG 758. Author, publication date, and exact bibliographic title to be confirmed during source registration.
https://academy.iccwbo.org/trade-finance/article/understanding-demand-guarantees-urdg-758-guide/

The ICC Academy article is explanatory material. Detailed analysis of URDG 758 must consult the applicable rules themselves and establish whether the instrument incorporates them.

13.6 Architecture Documentation

The following x-change documents inform the conceptual framework:

1. docs/architecture/SETTLEMENT_OS_COMPASS.md
2. docs/architecture/TREASURY_INITIAL_STATE_AND_ACCOUNT_PORTFOLIOS.md
3. docs/architecture/VOUCHER_CLAIM_OUTCOME_PROTOCOL.md
4. docs/PAY_CODE_PAYMENT_FLOW.md
5. docs/architecture/on-demand-issuance-funding/ON_DEMAND_ISSUANCE_FUNDING_COMPASS.md
6. docs/architecture/public-auto-generate/PUBLIC_AUTO_GENERATE_COMPASS.md
7. docs/architecture/public-auto-generate/CHECKOUT_COMPASS.md
8. docs/architecture/public-auto-generate/TESTING_INSTANCE_ACCEPTANCE_COMPASS.md

Public issuance source and test definitions were inspected on 2026-11-03 against the clean x-change checkout at commit 13b80ba7eba361e0f7dae67bd14579dffb59b849. Paths below are relative to the x-change repository:

1. routes/web.php — public /x/auto-generate group, separate from authenticated operator routes.
2. src/Http/Middleware/UseCommercialPrincipalForPublicIssuance.php — configured public-issuance principal and request context.
3. src/Http/Controllers/Web/PublicAutoGeneratePageController.php — public surface and full-amount funding policy.
4. src/Http/Controllers/Web/Cockpit/CockpitQuickGenerateMutationRouteShellController.php — public order preparation.
5. src/Actions/IssuanceBatch/PrepareIssuanceBatchFunding.php — full-amount batch funding, including the single-item public path.
6. src/Services/Funding/OnDemandIssuanceFundingRequirement.php — full-amount versus Client Funds shortfall calculation.
7. src/Actions/Funding/PrepareOnDemandPayCodeIssuance.php — issuance funding-order preparation.
8. src/Services/PublicIssuance/PublicIssuanceOrderAccess.php — guest token and session authorization.
9. tests/Feature/PublicAutoGeneratePageTest.php — inspected public-rendering and pre-issuance order assertions.

This baseline supports source-level observations only. No test execution, new live transaction, deployed-version verification, or complete escrow implementation audit is claimed. Older compass entries and their reported release evidence must retain their original scope.

For each document, the evidence register must identify the repository revision, relevant section, date reviewed, and supporting implementation evidence where available.

Documentation describes the project’s design and reported capabilities. It does not independently demonstrate production behavior.

13.7 Research Governance Documents

The study follows the research disciplines described in:

1. Source Evaluation Protocol
2. Research Workflow
3. Legal Characterization
4. Regulatory Traceability Matrix

These are internal governance and architecture materials, not external legal authorities.

13.8 Outstanding Literature Work

Further review should address Philippine sources concerning manager’s checks, money orders, documentary credits, guarantees, agency, and the distinction between deposits and entrusted funds.

The literature review should also examine independent scholarly work, comparable products, and empirical research on conditional payments, customer trust, adoption, disputes, and operating costs.

Until that work is completed, the bibliography should be described as a preliminary source base rather than a comprehensive literature review.

13.9 Market and Product Sources

The following first-party pages were reviewed on 2026-11-03 for the access-model comparison in Section 4.7:

1. Chinabank. Escrow FAQs. Publication/revision date not established.
   https://www.chinabank.ph/investments-faqs-escrow
2. M Lhuillier. ML ShopSafe. Publication/revision date not established.
   https://mlhuillier.com/ml-shopsafe
3. Dragonpay. (2019, December 12). Dragonpay: Continues to Lead the Alternate Payment Solutions! Historical SureTayo provider description; present availability unverified.
   https://www.dragonpay.ph/dragonpay-continues-to-lead-the-alternate-payment-solutions/
4. Escrow.com. What Is Escrow.com? Publication/revision date not established.
   https://www.escrow.com/what-is-escrow
5. Escrow.com. Inspection Period. Published inspection, non-response, return, and dispute procedures; publication/revision date not established.
   https://www.escrow.com/inspection-period
6. Trustap. Identity and Users. Live technical documentation; exact revision identifier not captured.
   https://docs.trustap.com/docs/guides/transactions/users

These sources evidence published product descriptions, not independently verified outcomes or legal opinions. Formal comparison requires archived versions, current service confirmation, complete terms, and jurisdiction-specific availability. They do not establish demand for x-change or an absence of other competitors.

Appendices

Appendix A: Transaction Lifecycle and State Diagrams

A.1 Purpose and Status

This appendix illustrates the proposed lifecycle of a funded conditional obligation. The states are conceptual product states, not assertions about existing database fields or implemented behavior.

The initial model assumes one full settlement per obligation. Partial releases would require a separately specified extension covering amounts, remaining commitments, and independent execution outcomes.

A.2 Funding Paths

Both funding paths must establish attributable value before the obligation becomes available for release.

flowchart TD
    R[Transaction terms and institutional acceptance] --> P{Funding path}
    P --> C[Optional existing Client Funds]
    C --> V[Verify authority and available amount]
    V --> H[Create transaction-specific reservation]
    P --> F[Primary public Pay and Issue]
    F --> E[Verify incoming funding evidence]
    E --> A[Attribute required amount to request]
    A --> H
    H --> I[Issue Pay Code and preserve escrow commitment]
    I --> W[Await applicable release conditions]

Issuance and reservation must be coordinated so that interrupted processing cannot create an active, unbacked instruction or leave an unexplained commitment. Recovery procedures must address funding received before issuance completes.

Public funding does not create a purchaser spending balance. The diagram describes the proposed extension: an issuance hold must transition into continuing escrow backing without double-counting or authorizing premature payout.

A.3 Separate State Dimensions

A single status cannot adequately describe the obligation.

These dimensions interact through explicit transition rules. Code expiry, for example, does not automatically cancel the obligation or release its reservation.

A.4 Release and Execution

flowchart TD
    C[Claim presented] --> V[Validate code, claimant, and governing version]
    V --> Q{Release conditions satisfied?}
    Q -->|No| W[Remain pending or enter review]
    Q -->|Yes| A[Record authorized release]
    A --> G[Atomically verify reservation, holds, and prior execution]
    G --> S[Submit tracked execution attempt]
    S --> O{Authoritative outcome}
    O -->|Success| J[Record settlement and consume commitment]
    O -->|Definitive failure| F[Retain commitment and assess recovery]
    O -->|Unknown| U[Retain commitment and investigate]
    U --> O
    F --> R[Authorize next action under governing rules]

An uncertain attempt blocks a conflicting payment or refund until its outcome is resolved. A retry following definitive failure must remain linked to the same obligation and prevent a second successful fulfillment.

A.5 Alternative Dispositions

Settlement and refund must be mutually exclusive for the same committed amount. Reversals must preserve the original history rather than erase it.

A.6 Transition Record

Every material transition should identify:

1. The obligation and governing instruction version.
2. The actor or process requesting the change.
3. The authority permitting the action.
4. The evidence evaluated.
5. The previous and resulting states.
6. The amount and accounting consequences.
7. The operation and execution references.
8. The time and outcome of the action.

Sensitive evidence may be held in controlled storage with durable references. Traceability does not require copying all personal information into every record.

A.7 Closure and Continuing Accountability

Closure requires a recorded disposition of the obligation and its associated amounts, together with the required reconciliation evidence.

An operational case may remain open after payment where a dispute, reversal, or accounting exception requires further action. Conversely, an expired code may leave an unpaid obligation requiring resolution.

The product must therefore distinguish completion of a payment, closure of an obligation, and resolution of an operational case.

Appendix B: Comparative Instrument Matrix

B.1 Purpose and Limits

This matrix compares the functions relevant to the proposed service. It does not establish that a Pay Code legally qualifies as any listed instrument or that every bank may offer every arrangement.

The comparisons focus on the obligation, release trigger, and lessons for product design. Detailed treatment of cancellation, transferability, defenses, and institutional authority requires further source review.

B.2 Functional Comparison

B.3 Source Basis

The Negotiable Instruments Law defines a check as a bill of exchange drawn on a bank and payable on demand. Its formal requirements also matter when comparing a conditional digital instruction with a negotiable instrument. A functional analogy does not establish compliance with those requirements. Act No. 2031, Sections 1 and 185

Philippine jurisprudence describes a manager’s check as ordinarily becoming the issuing bank’s primary obligation. The same discussion distinguishes issuance from an automatic transfer of funds to the payee. Supreme Court, G.R. No. 192413

The documentary-credit and demand-guarantee comparisons draw on the explanatory sources listed in Section 13. Detailed analysis requires the relevant instrument terms and applicable rules. International Trade Administration, ICC Academy

The escrow and e-money comparisons draw on the BSP sources already identified in the paper. BSP Circular 609, BSP Circular 1166

B.4 Questions That Distinguish the Candidate Models

The product specification must answer:

1. Does the bank undertake to pay in its own capacity, administer entrusted property as an agent, or perform another defined role?
2. Who has entitlement to the funds before and after the release conditions are satisfied?
3. Is payment dependent on documentary presentation, an authorized decision, or another event?
4. Can the funding principal cancel, and when does that right change?
5. Can the recipient transfer the claim or designate another recipient?
6. What happens when performance is disputed or payment execution is uncertain?
7. Does unused value remain tied to the original obligation or become reusable?
8. Which institution bears each obligation, and under what authority?

B.5 Implication for Product Naming

The comparison supports retaining digital escrow as a working product concept while specifying the bank’s actual undertaking.

A product involving an escrow appointment and conditional administration of entrusted funds may support that description. A product centered on the bank’s own payment promise may require a different characterization, even if it uses the same Pay Code and settlement machinery.

The architecture should preserve these distinctions rather than allowing a shared interface or product name to determine the underlying relationship.

Appendix C: Scenario and Evidence Matrix

C.1 Purpose and Status

This matrix translates the proposed lifecycle and invariants into evaluation scenarios. It specifies expected behavior and the evidence needed to assess it.

All scenarios are proposed and unevaluated within this study. An expected outcome is a requirement to investigate, not a reported result.

C.2 Funding and Issuance

C.3 Conditions and Release Authority

C.4 Execution and Recovery

C.5 Cancellation, Expiry, and Refund

C.6 Reconciliation and Bank Operation

C.7 Evaluation Record

Each executed scenario should record:

1. Product version, configuration, environment, and date.
2. Preconditions, inputs, and authorized participants.
3. Expected behavior and pre-established acceptance criteria.
4. Actual outcome and evidence references.
5. Accounting effects and unresolved exceptions.
6. Reviewer, interpretation, and required follow-up.

Scenario status should distinguish not evaluated, passed within scope, failed, blocked, and inconclusive. A blocked or inconclusive case must not be counted as a pass.

C.8 Coverage and Interpretation

The matrix provides initial coverage for architectural fit, operational integrity, and bank operability. Customer utility and commercial feasibility require the separate inquiry and measures specified in Sections 6 and 8.

Scenario C24 requires a defined accounting model. It must not assume that an external bank balance equals available customer funds: committed amounts, fees, pending executions, and other recorded positions must be explained.

Successful evaluation supports only the tested version, configuration, and conditions. New features, changed provider behavior, or revised agreements may require additional scenarios and renewed evaluation.

Appendix D: Open Questions and Decision Log

D.1 Purpose

This appendix preserves unresolved questions and the reasoning behind product decisions. It connects changes in the proposed model to their evidence and consequences.

Working assumptions remain revisable. Recording a direction in this thesis does not establish bank acceptance, legal approval, or demonstrated capability.

D.2 Initial Open Questions

All questions below are open. Suggested review roles identify the expertise needed; they are not assignments accepted by named participants.

D.3 Working Directions Recorded in This Thesis

These entries capture the current proposed scope. They remain subject to evidence and institutional agreement.

D.4 Decision Record Format

Each material decision should record:

1. Identifier, date, status, and responsible decision-maker.
2. Question addressed and relevant scope.
3. Alternatives considered.
4. Evidence, assumptions, and adverse arguments.
5. Chosen direction and rationale.
6. Consequences for customer rights, accounting, architecture, and operation.
7. Affected requirements, scenarios, and document versions.
8. Review conditions and any superseding record.

A decision must not be marked accepted without an identifiable decision-maker and defined scope. Acceptance within the research project does not imply acceptance by a bank, counsel, or regulator.

Material legal architecture decisions should link to the package’s Legal Decision Records rather than develop a conflicting approval process.

D.5 Question and Decision Status

Questions may be open, under investigation, answered within a defined scope, deferred, or superseded.

Decisions may be proposed, accepted for a defined scope, rejected, or superseded.

An answered question must identify its supporting evidence and limitations. Deferred questions must state why they can remain unresolved and whether they block the next research or deployment step.

D.6 Revision Triggers

The thesis should be reconsidered when new evidence changes a material assumption, including:

1. A different institutional role or contractual undertaking.
2. A relevant change in authority or interpretation.
3. A control failure or unexplained reconciliation result.
4. Customer findings inconsistent with the proposed experience.
5. Costs inconsistent with commercial feasibility.
6. A feature that introduces reusable value, transferability, partial releases, lending, or another excluded activity.

Each revision should identify which hypotheses, scenarios, and earlier conclusions require renewed evaluation.

D.7 Initial Research Priority

The first priority is to resolve Q01 and develop Q02: select the initial use case and state the bank’s promise.

Those outputs provide a concrete basis for institutional analysis, architecture mapping, customer evaluation, and pricing. Subsequent decisions should remain traceable to that defined product rather than to digital escrow as an abstract label.

Appendix E: Initial Use Case and Proposed Bank Undertaking

E.1 Purpose and Status

This appendix develops the recommended initial candidate: a one-time domestic PHP purchase of specified physical goods through public on-demand funding, with one full release after buyer acceptance or an authorized resolution. Transaction values, holding periods, and eligible goods must be bounded before evaluation.

The scenario makes the proposed product concrete enough to examine customer rights, institutional responsibilities, release authority, and operational requirements. It is a candidate for evaluation, not a selected pilot or an approved bank product.

The proposed undertaking below expresses product intent. It is not an executable agreement or a concluded legal characterization.

E.2 Customer Problem

A buyer may be unwilling to pay a seller before receiving goods. A seller may be unwilling to deliver without confidence that payment is available.

A transaction-specific commitment could address this coordination problem. The buyer funds the transaction through the bank, and the seller receives authenticated confirmation that the required amount is committed under agreed conditions.

The service must explain the limits of that assurance. Confirmation of funding does not establish that goods meet their description, and the proposed arrangement does not eliminate delivery fraud or disputes.

E.3 Parties and Responsibilities

The bank’s administration of release conditions should be distinguished from responsibility for assessing the goods. The agreement must identify who decides a disagreement and the scope of that decision-maker’s authority.

E.4 Proposed Bank Undertaking

A working statement of the bank’s promise is:

Upon verifying receipt of the required funding and accepting the transaction, the bank will record the amount committed to the identified obligation and administer its disposition under the agreed terms.

The bank will authorize payment to the verified seller when the defined release conditions are satisfied, subject to applicable holds and requirements. Cancellation, disputes, refunds, and unresolved amounts will follow the agreed procedures.

The bank will preserve a record of funding, authorization, execution, and disposition. Where execution is uncertain, it will investigate the existing attempt before permitting a conflicting payment or refund.

Before use, this statement requires detailed treatment of the custody arrangement, customer entitlements, fees, timelines, liability, and the bank’s institutional role.

E.5 Transaction Formation and Funding

The buyer and seller first identify the transaction: goods, price, delivery requirements, inspection period, release conditions, and dispute process. Both parties must accept the terms that affect their rights.

The primary journey uses public Pay and Issue: the purchaser funds a specific order without opening a platform Account or reusable wallet. The institution must still obtain required identification and evidence of agreement. Existing Client Funds may support a separately evaluated alternative. The committed amount, seller entitlement, fees, and total required funding must be separately identifiable.

After funding is verified and the reservation is recorded, the service issues a Pay Code associated with the obligation and its governing terms. The transition from issuance funding to the continuing escrow commitment must retain backing and prevent payout while release conditions remain unmet.

The seller should verify the funded status through a bank-controlled channel with access controls appropriate to the disclosed information; a conventional platform Account is not inherently required. A screenshot, forwarded message, or possession of the code alone should not be treated as authoritative confirmation or release authority.

E.6 Delivery, Acceptance, and Release

The seller delivers the agreed goods and submits any required delivery evidence. The service records when the inspection period begins under the agreed rules.

The buyer may then accept the goods or raise a dispute. Acceptance must be attributable to an authorized buyer action and linked to the relevant transaction.

Before payment submission, the bank checks the reservation, release authority, recipient destination, applicable holds, and prior execution attempts. Settlement is recorded only upon sufficient authoritative evidence.

For the initial candidate model, buyer silence does not automatically authorize payment. The agreement must provide a bounded process for non-response so that funds do not remain unresolved indefinitely.

E.7 Cancellation and Exceptional Outcomes

A dispute hold should identify its scope, authority, and review deadline. The service must distinguish preventing a payment that has not been submitted from attempting to recover a payment already executed.

E.8 Illustrative Transaction

A buyer agrees to purchase equipment for ₱50,000. Assume a separately disclosed service fee has been funded in addition to that amount.

1. Buyer and seller accept the transaction terms.
2. The buyer funds the specific public issuance order without platform login or reusable wallet funding.
3. The bank verifies funding and reserves ₱50,000 against the obligation.
4. A Pay Code is issued with continuing escrow backing, and the seller verifies the commitment through the bank’s channel.
5. The seller delivers the equipment.
6. The buyer inspects it within the agreed period and records acceptance through transaction-specific authentication, without a mandatory platform Account.
7. The bank validates release authority and submits one payment to the verified seller destination.
8. Authoritative evidence confirms settlement.
9. The bank records the disposition and reconciles the transaction.

If the buyer disputes the equipment’s condition at step 6, the normal release path stops. The agreed decision process determines whether payment, refund, return of goods, or another permitted disposition follows.

This example illustrates the proposed workflow. It is not evidence of an executed transaction or an accounting specification.

E.9 Questions Requiring Resolution

Before evaluating the use case, the product team must determine:

1. Which goods and transaction values are suitable for the initial scope?
2. How do the parties agree on the goods and acceptable delivery evidence?
3. Who may accept, dispute, amend, or cancel?
4. What starts the inspection period, and how long does it last?
5. What resolves buyer non-response?
6. Who decides disputes, using what evidence and deadlines?
7. What happens when a return is incomplete, damaged, or contested?
8. How are fees treated after cancellation, dispute, or refund?
9. What custody arrangement and institutional authority support the bank’s undertaking?
10. What happens if the service or a participant becomes unavailable while funds remain committed?

E.10 Evaluation and Relationship to the Thesis

Evaluation should examine whether the proposed commitment gives sellers sufficient confidence to deliver and buyers sufficient confidence to fund. It should also test whether both parties understand release conditions and whether the bank can administer exceptions at a sustainable cost.

The scenario should be mapped to Appendix C, supplemented by delivery, acceptance, non-response, and return-of-goods cases.

If the evidence supports proceeding, this appendix can become the basis for a versioned product specification. Changes to its assumptions and undertaking should remain linked to the question and decision log in Appendix D.

Appendix F: Disbursable, Payable, and Settlement Vouchers Within a Common Framework

F.1 Purpose and Source Basis

This appendix connects ordinary input-gated disbursement, payable collection, and staged settlement within the proposed product framework.

The discussion draws on the x-change documents docs/voucher-flow-matrix.md, docs/collectible-voucher-execution.md, and docs/flow-type-decision-record.md. These contain architectural descriptions and technical terminology whose implementation scope must be established through the versioned evidence process.

In this appendix, payable describes the payer-facing collection scenario associated with the documented collectible flow. The amount is payable by the payer to the designated collection destination; it is not necessarily a liability owed by the voucher issuer.

F.2 Common Architecture

Each flow connects a financial instruction with actors, evidence, authorization, execution, and accounting.

The direction of movement differs:

A shared interface or Pay Code does not make these flows financially identical. Their funding requirements, authorized actors, completion rules, and accounting consequences must remain explicit.

F.3 Ordinary Disbursable Pay Code With Input Requirements

An ordinary disbursable Pay Code may express an instruction such as:

Pay the eligible beneficiary ₱5,000 after the specified identity and acknowledgment requirements have been satisfied.

The issuer defines the permitted recipient or eligibility rule, amount, required inputs, and release policy. The claimant supplies the necessary information, and the system evaluates it under the governing instruction.

Required inputs might include a mobile number, OTP, identity evidence, location, selfie, signature, or supporting document, depending on the product configuration.

Four concepts must remain separate:

1. Input requirement: What must be supplied?
2. Validation rule: What makes the input acceptable?
3. Approval authority: Who may determine that a condition is satisfied?
4. Release rule: Which evidence and approvals permit payment?

Collecting an input does not necessarily establish the fact it concerns. A signature may acknowledge receipt without proving delivery of goods. An OTP may support control of a mobile number without establishing contractual entitlement.

F.4 Payable or Collectible Voucher

A payable scenario begins with a request for payment rather than a prepaid outward obligation.

For example:

Collect ₱5,000 from the payer for the identified invoice and attribute the verified receipt to the designated collection destination.

The reviewed collectible documentation distinguishes prepaid value from the requested target amount. A collection target does not itself establish that funds have been received.

Its documented flow includes payment instructions, provider evidence, collection recording, and progress toward the target. It also distinguishes the Pay Code QR, which identifies the route, from the provider-issued payment-rail QR used to make the payment.

The collection destination must be explicit. Receipt verification must prevent the same provider transaction from being recognized against multiple obligations.

A payable voucher may complete upon collection under its applicable policy. Where collection is followed by a conditional release, an additional settlement relationship must connect the receipt to that later obligation. Collection alone must not silently authorize onward payment.

F.5 Settlement Voucher

A settlement voucher coordinates stages whose financial actions depend on a defined policy.

The reviewed flow matrix describes patterns including collection followed by conditional release and disbursement followed by collection. These are architectural patterns; their appearance in the matrix does not establish legal classification or complete implementation.

For this thesis, the principal pattern is:

Payment request
    ↓
Verified collection
    ↓
Transaction-specific attribution and commitment
    ↓
Required evidence and approvals
    ↓
Authorized release
    ↓
Confirmed settlement and reconciliation

The implementation must specify whether one settlement voucher governs the stages or whether explicitly linked vouchers represent them. This appendix does not assume that either representation is already established for the proposed product.

Where separate vouchers are used, their relationship must prevent the collection stage from being counted twice or the outward obligation from exceeding the committed amount.

F.6 Role of the Settlement Envelope

The reviewed architecture describes the Settlement Envelope as a proof container and readiness gate. It separates that role from balance holding and payment execution.

For the proposed product, the envelope would organize or reference the evidence required for a stage to proceed. Depending on the use case, this could include identity evidence, delivery records, buyer acceptance, required approvals, and dispute status.

The responsibilities can be expressed as follows:

Envelope readiness should be a prerequisite where required, rather than sufficient authority for every payment. Before execution, the system must still check current holds, available commitment, governing version, and prior attempts.

A previously ready envelope must not bypass a subsequently applicable dispute hold or allow duplicate execution.

F.7 Applying the Envelope Across the Three Scenarios

Disbursement. The envelope may organize claimant inputs and acknowledgment evidence. Once the required evidence is accepted, the issuer’s applicable instruction and authorization policy determine whether payment may proceed.

Payable collection. The envelope may organize invoice details, payer information, and supporting records. Evidence completion does not substitute for authoritative confirmation that payment was received.

Conditional settlement. The envelope may span stages and actors, organizing funding references, delivery evidence, acceptance, approvals, and dispute decisions. Each stage must have its own readiness and authorization rules.

This permits reuse of the evidence framework while preserving the different meanings of payment received, claimant verified, performance accepted, and release authorized.

F.8 Worked Purchase Scenario

For the equipment purchase in Appendix E:

1. Buyer and seller accept the governing terms.
2. A payable collection stage requests the required funding.
3. Provider evidence establishes the receipt.
4. Treasury records attribute and commit the amount to the purchase obligation.
5. The Settlement Envelope records or references delivery evidence.
6. The buyer’s authorized acceptance satisfies the applicable performance condition.
7. Current holds, recipient details, commitment, and previous execution attempts are checked.
8. The release action is authorized and submitted.
9. Authoritative settlement evidence and accounting records complete the financial stage.

If the buyer disputes delivery, the envelope records the unresolved condition and relevant decision process. The funds remain subject to the agreed hold and disposition rules.

If the provider outcome is uncertain after submission, an otherwise ready envelope does not authorize another payment.

F.9 Relationship to the Digital Escrow Thesis

Ordinary input-gated disbursement provides a simpler instance of governed settlement. Payable collection provides the inward funding path. Settlement vouchers and envelopes offer a way to coordinate stages involving additional evidence, actors, and decisions.

Their combination supplies an architectural basis for investigating digital escrow. It does not independently establish an escrow agency arrangement or institutional authority.

The proposed product therefore extends a common foundation while requiring explicit agreements, release policies, exception procedures, and evidence of implementation.

F.10 Additional Evaluation Requirements

Appendix C should be extended to examine:

1. A collection receipt linked to one subsequent settlement obligation without duplicate attribution.
2. A collection target reached while release conditions remain incomplete.
3. A complete evidence submission containing invalid or rejected proof.
4. Approval by the wrong actor or under an obsolete instruction version.
5. A dispute introduced after envelope readiness but before payment submission.
6. Repeated envelope evaluation without repeated financial execution.
7. Failure between verified collection and reservation creation.
8. Reconciliation across collection, commitment, release, fees, refunds, and unresolved stages.

These remain proposed evaluation cases until executed against a defined product version and operating configuration.

Revision Priorities

Confirm the bounded initial use case and bank undertaking; register current
authorities and competitor terms; map the public issuance baseline to escrow
requirements; and evaluate agreement, continuing backing, party permissions,
guest recovery, disputes, and refunds. Test customer value and exception-inclusive
economics before making stronger readiness or market-creation claims.

Knowledge System disposition: This is an exploratory research artifact. Future
reviewed findings may inform Knowledge Articles, characterization, invariants,
and decision records through the existing governance process.