A payments company decides to add stablecoin settlement. That sounds like one product decision. It is not.
In the rooms we have sat in, the question that reaches the board is usually "are we allowed to do this?" We think that is the wrong shape of question. There is no single stablecoin settlement design, and the position produced by one design is not the position produced by another.
The variables that decide the answer are unglamorous. Who holds the asset. Where it sits. What the customer receives in substance. Whether value can move to a third party. Whether the institution ever carries a balance of its own.
The same objective, three different institutions
Illustrative example. A US B2B payments company wants same-day settlement for cross-border payouts. Three configurations get it there.
Settling through a regulated counterparty puts most of the consequence into a dependency. The institution's position becomes partly a function of someone else's permissions and someone else's behaviour.
Holding balances directly moves the consequence inside the institution. The commercial outcome can be identical; the operating model that has to exist behind it is not — treasury, reconciliation, controls, licensing work, and the teams who now own all of it.
A hybrid, with an on-chain settlement leg behind a conventional customer experience, splits the consequence across the two legs. Sometimes that is the smallest delta. Sometimes it is the hardest thing to evidence to a partner bank.
Why the sequencing matters commercially
Settlement design is expensive to reverse. Once it is in production, discovering that a different configuration would have produced a materially smaller Regulatory Delta costs quarters, not weeks — engineering rework, re-papering, counsel time, and revenue that arrives later than the plan said it would.
That is why we keep separating simulating the decision from researching the environment. A list of applicable rules does not tell you which of your three designs to build. A comparison of what each one changes does.
What is testable, and what is not
Before commitment, management should be able to see the two or three viable configurations, what each changes about the institution, which states change the answer, and where the answer rests on judgement rather than fact.
Some of that is computationally testable: does the institution hold customer-attributable value, whose permissions does it rely on, which state activities are touched. Some of it needs expert interpretation, and some of it may need a conversation with a regulator or a partner bank's credit committee.
We are not building Reglator to remove that judgement. We are building it so the repeatable part is reproducible and the expert attention lands on the part that actually turns on interpretation. This is the kind of decision we want to make testable before anyone writes code.