In most stablecoin programmes we have looked at, the custody model is settled early, quietly, and for practical reasons. A counterparty is already integrated. A wallet provider is already contracted. Someone picks the path of least engineering resistance.
It then becomes one of the hardest things to change and one of the largest determinants of where the institution sits.
Three questions that decide the shape
Does the institution ever hold a customer-attributable balance? Can value leave to a third party on the customer's instruction? Does the institution rely on someone else's permissions for either?
Those three answers place the product in different parts of the design space, with different operating models behind them, regardless of how similar the front end looks to the customer.
Simulate custody before integration
The useful sequence is to compare custody configurations while they are still cheap to change: before contracts, before integration work, before the proposition has been described publicly or to a partner bank.
This is a simulation exercise rather than a research exercise. The question is not what the rules say in general. It is what each configuration would change for this institution — and which of those changes are deterministic versus dependent on facts that still need analysis.
A wallet provider taking custody for the first time is our standard illustrative case here, because almost nothing about the product changes and almost everything about the institution does.