This founder’s update records the state of the work and its institutional conversations as of June 2026. References to exploratory discussions and integrations do not imply endorsement, certification, or production adoption by the organizations named.
Where It All Began
People often ask how x-change began. Most assume it started with an idea about banking or financial technology. It did not. It started with a practical problem.
Several years ago, I became involved in designing a system for distributing financial assistance (Ayuda) at the local government level during an election period. On paper, the problem appeared straightforward. A government agency had funds. Beneficiaries needed to receive them. Banks and payment providers already existed.
Yet the closer I looked, the more I realized that moving money was only a small part of the challenge. The real work happened before and after every transfer.
Who was entitled to receive the funds? Had all the documentary requirements been completed? Who approved the release? Could the recipient be verified? What happened if the recipient was unavailable? What if additional supporting documents were required? What if the payment had to be delayed, cancelled, redirected, or partially fulfilled?
Every answer introduced another operational step. The transfer itself was rarely the bottleneck. The surrounding process was.
At first, I believed I was building a better way to transfer funds. Looking back, I realize I was observing something much larger. The problem was never simply about moving money. It was about managing the obligations, decisions, approvals, and coordination that surround every financial settlement.
That realization became the starting point of what would eventually evolve into x-change.
The Platform Began to Teach Me
What surprised me most over the following years was that every attempt to simplify the platform exposed another layer of complexity. Each version solved one problem while revealing another. The platform itself kept teaching me.
The first versions were little more than a mechanism for initiating pull-based fund transfers. The objective was straightforward: instead of pushing money directly to a recipient, create a controlled way for recipients to claim funds that had already been allocated to them.
That worked. Until real-world deployments introduced new questions. Not every recipient should be able to redeem immediately. Some transactions required additional information before settlement could occur. Others required identity verification, supporting documents, signatures, photographs, location information, or the completion of specific business processes.
The transfer itself had become only one step within a much larger workflow. That realization led to the introduction of configurable input requirements and gated redemption. Redemption was no longer simply the act of receiving money. It became the successful completion of a series of conditions defined by the issuer.
As the platform matured, another observation emerged. Financial obligations often carried more than money. They carried instructions. Approvals. Evidence. Supporting documents. Future actions. Relationships between multiple parties.
To accommodate these realities, the concept of the Settlement Envelope gradually emerged. Instead of treating settlement as a single transaction, the platform began treating it as a complete package containing everything necessary to fulfill a financial obligation.
Yet even that proved insufficient. Some obligations did not end when money was disbursed. Payments generated receipts. Receipts triggered approvals. Approvals initiated new obligations. Some transactions flowed in both directions. Money no longer moved in a straight line. It moved through a lifecycle.
This eventually led to the idea of bidirectional settlement and, ultimately, to what I now call Portable Settlement Contracts—financial obligations that can be carried independently of the institution or payment rail that eventually fulfills them.
Looking back, I now realize that each architectural change was pointing toward the same destination. I was no longer building a better payment platform. I was gradually discovering the components of a Settlement Operating System.
That realization did not happen in a single moment. It emerged one question, one deployment, and one refinement at a time. In hindsight, the architecture was evolving toward its destination long before I had the words to describe it.
What Changed
If there is one lesson this journey has taught me, it is that the most important breakthroughs are often conceptual rather than technical. For a long time, I believed I was building a better payment platform. The software became more capable. The architecture became more sophisticated. The workflows became richer. Yet something still felt incomplete.
Eventually, I realized I had been asking the wrong question.
“How do we move money?”
Modern payment rails already move money remarkably well. Banks. Real-time payment networks. Digital wallets. International remittance providers. All continue to improve in speed, cost, and accessibility. The real challenge lies elsewhere.
Every financial transaction begins long before money moves and often continues long after settlement has occurred. Someone must create an obligation. Someone must define the conditions under which it may be fulfilled. Evidence may need to be collected. Approvals may need to be granted. Exceptions may need to be handled. Settlement must eventually occur. Receipts may trigger new obligations.
Viewed this way, payment is no longer the central event. It is simply one stage in a much larger lifecycle. That realization fundamentally changed the direction of the platform.
Instead of asking, “How do we build a better payment system?” I began asking: “How do we represent, manage, and ultimately fulfill financial obligations regardless of where or how settlement eventually occurs?”
That shift changed everything. Payments became an implementation detail. Obligations became the primary object of the system. Settlement became one possible outcome.
The platform was no longer evolving toward another financial application. It was evolving toward something much broader—a settlement operating system capable of coordinating financial obligations throughout their entire lifecycle.
Looking back, I no longer see x-change primarily as a payment platform. I see it as an operating system for financial settlement. Everything else—the Pay Code, Portable Settlement Contracts, x-Payout, and the execution engine now under development—is a natural consequence of that single conceptual shift.
The Company Around the Technology
As the platform matured, it became increasingly clear that developing the technology was only one part of the journey. Building software and building an institution are two very different challenges.
To prepare for the eventual commercialization of x-change in the Philippines, I began assembling the organizational foundation that could support the technology beyond its research and development phase. One important step was establishing the Open Disbursement Technology Institute (ODTI) as the operating organization that will help introduce and commercialize the platform locally while allowing the underlying technology to remain licensable to other countries and markets.
To help lead this effort, I partnered with Mr. Guido Delgado, whose experience complements my own technical background. Mr. Delgado previously served as President and Chief Executive Officer of Mindanao Development Bank and later as President of the National Power Corporation (NAPOCOR), one of the Philippines' largest government-owned corporations. His experience in banking, public institutions, and organizational leadership provides the commercial and institutional perspective necessary to complement the technical evolution of the platform.
This partnership reflects an important transition. x-change is no longer simply a research project or a software platform under continuous development. It is gradually becoming an organization capable of engaging financial institutions, government agencies, strategic partners, and international collaborators.
My focus remains the continued evolution of the technology. ODTI is intended to provide the organizational foundation through which that technology can be responsibly introduced, deployed, and ultimately licensed both within the Philippines and, in time, internationally.
I have come to believe that enduring technologies require more than good engineering. They require institutions capable of carrying those ideas into the real world.
Validation
As the platform evolved, I made a conscious effort to validate the technology through real-world engagement rather than assumptions. Each conversation, integration, and milestone has helped reduce uncertainty and refine both the architecture and its commercial direction.
The technology itself is now patent pending in the Philippines, reflecting the belief that the architectural concepts underlying x-change represent a novel approach to financial settlement.
From a technical perspective, I have successfully integrated x-change with the API platforms of Netbank and Paynamics. These integrations have been used strictly for research and development purposes, allowing the platform to execute real financial workflows while continuously refining the settlement model.
Equally important has been regulatory engagement. I presented the concept to Mr. Dennis Bancod, who heads the Payments Policy and Development Department of the Bangko Sentral ng Pilipinas (BSP). The discussions were constructive and provided confidence that the underlying direction of the platform is aligned with the continuing modernization of the Philippine payments ecosystem.
The commercial hypothesis has also been tested through discussions and demonstrations with several financial institutions, including Maya, LandBank of the Philippines, and EastWest Bank. These engagements remain exploratory but have provided valuable feedback that has directly influenced the evolution of the platform.
More recently, encouraging progress has been made with the Development Bank of the Philippines (DBP). Current discussions are moving toward a formal Proof of Concept, which, if successfully completed, would provide the first institutional implementation of x-change within a government financial environment.
Taken individually, none of these milestones represents the destination. Collectively, however, they provide a consistent pattern of validation.
The technology has progressed beyond theory. It has attracted the attention of regulators, financial institutions, payment providers, and potential implementation partners. Each engagement has strengthened the conviction that the problem x-change seeks to solve is both real and widely recognized, even if the solution continues to evolve.
AI Changed Everything
One unexpected development over the past year has been learning how to work effectively with modern AI coding agents. Tools such as Warp and OpenAI Codex have become an integral part of the way I design, implement, and continuously refine x-change.
Contrary to popular perception, these tools do not replace software engineering. They amplify it. I have found that the quality of the output depends far less on the AI itself than on the clarity of the architecture, the precision of the instructions, and the discipline with which the system is designed.
In many ways, x-change has become an ideal environment for this style of development. Because the platform is built around explicit architectural principles and carefully defined package boundaries, AI agents can scaffold substantial portions of the implementation while still preserving the overall design intent.
The greatest benefit has not been writing code faster. It has been accelerating experimentation. Architectural ideas that might once have required weeks to prototype can now be explored, evaluated, refined, or discarded in a matter of days. This has fundamentally changed the pace at which the platform evolves.
Interestingly, I have also discovered that effective collaboration with AI is itself a skill that must be learned. Rather than placing the system into fully autonomous mode, I deliberately work alongside the agents, reviewing each proposal, refining the architecture, and allowing the platform itself to guide the next iteration. That slower, more deliberate process has often produced better long-term results than simply maximizing automation.
I now view AI less as an automatic code generator and more as an engineering multiplier. It expands the number of ideas that can be explored without reducing the level of architectural rigor required to build a platform intended to operate at financial-infrastructure scale.
If additional resources become available, I believe this human-AI development model can substantially accelerate the continued evolution of x-change while preserving the design discipline that has shaped the platform from the beginning.
Where We Are Today
Today, x-change occupies a very different place from where it began. It is not yet a commercial product deployed at scale. It is not yet a widely adopted financial platform. But it is no longer simply an idea.
Years of iterative development, real-world deployments, architectural refinement, and continuous validation have transformed it into a coherent platform with a clear direction. I now believe x-change has evolved into what it was gradually becoming all along—a Settlement Operating System.
The recent work on Portable Settlement Contracts and the Execution Engine represents the final architectural layer required to complete that vision. Together, they provide the foundation for coordinating financial obligations independently of the institutions, payment rails, or settlement methods that ultimately fulfill them.
With that foundation now largely in place, the next phase of the journey is no longer centered on discovering what x-change should become. It is centered on introducing it to the market.
To accomplish this, I have begun productizing the platform through x-Payout—the first commercial application built on top of x-change. Rather than presenting the broader operating system directly to customers, x-Payout focuses on solving an immediate and measurable business problem: removing the operational complexity surrounding organizational payouts while allowing the underlying platform to mature through real-world use.
At the same time, discussions continue with financial institutions, payment providers, and government agencies to explore pilot implementations and broader strategic collaborations.
Looking back, I find it remarkable how much the original objective has changed. I began by trying to improve the movement of money. I now find myself building the infrastructure that allows financial obligations to move with the same flexibility that information moves across the Internet.
Whether that vision ultimately succeeds will be determined by the market, the institutions that choose to participate, and the people who eventually use it. But I am more convinced today than at any point in this journey that the underlying problem is real, the architectural direction is sound, and the opportunity extends far beyond a single application or a single country.
The work continues—but for the first time, it feels less like inventing something new and more like uncovering something that was waiting to be discovered all along.
Why I Am More Optimistic Today
When I look back at where this journey began, I realize that my optimism today comes from a very different place than it once did.
It is not because I believe I have finally built the perfect technology. I have not. It is not because commercial success is already assured. It is not. And it is certainly not because funding has suddenly become easier.
The reason I am more optimistic is much simpler. The problem has become clearer. For many years, I focused on improving payments. Today, I believe the larger opportunity lies in improving financial settlement itself.
That single conceptual shift has provided a unifying explanation for nearly every architectural decision that x-change has made over the years. It explains why Pay Codes emerged. Why Settlement Envelopes became necessary. Why financial obligations needed to become portable. Why the platform evolved toward an execution engine. And ultimately, why x-change is better understood as a Settlement Operating System rather than another financial application.
Perhaps the most valuable outcome of the past several years has not been the software itself. It has been the gradual emergence of a coherent way of thinking about financial settlement.
That realization led me to write an accompanying paper entitled When Money Adapts to People—A Founder's Discovery Thesis on the Future of Financial Settlement.
The paper is not a product brochure, a technical specification, or an investment pitch. It is my attempt to explain the journey that transformed a practical engineering problem into what I now believe is a broader architectural discovery.
Whether that thesis ultimately proves correct will not be decided by me alone. It will be tested by engineers, financial institutions, regulators, governments, businesses, and, most importantly, by the people who use the systems we build.
If I have learned anything throughout this journey, it is that the best technologies rarely begin with better answers. They begin with better questions. I believe I am finally asking the right ones. The years ahead will determine whether the answers prove worthy of them.