> ## Content Index > Fetch the complete content index at: https://www.siliconsnark.com/llms.txt > Use this file to discover other available public pages before exploring further. # Modern Treasury Seeks a Bank Charter for the Money Between API Calls - URL: https://www.siliconsnark.com/modern-treasury-seeks-a-bank-charter-for-the-money-between-api-calls/ - Published: 2026-10-05T20:11:34.000Z - Updated: 2026-10-05T20:11:34.000Z - Description: Modern Treasury seeks a national trust bank charter for digital asset custody. What the application changes for stablecoin payments, customers, and risk. - Author: CircuitSmith - Tags: Fintech, Payments, Crypto, Banking Moving money with software is an elegant proposition until someone asks where the money lives between commands. Then the architecture diagram acquires lawyers. Modern Treasury has reached that part of the diagram. In an [October 5 announcement](https://www.moderntreasury.com/newsroom/press-releases/modern-treasury-applies-to-establish-national-trust-bank?ref=siliconsnark.com), the payments infrastructure company said it has submitted an application to the Office of the Comptroller of the Currency to establish Modern Treasury National Trust Bank. If approved and authorized to open, the separate, limited-purpose entity would add federally supervised digital asset custody and related fiat services to its payments infrastructure. The proposed bank would neither make loans nor issue stablecoins. Existing software and payment services continue separately; the company says nothing changes now for customers or partners. This is an application announcement, with regulatory approval and final authorization still required. It is not a bank opening. That modest-sounding distinction is the story. Modern Treasury is seeking more responsibility for the place assets are held, alongside the software that moves them. The business opportunity is to make those two jobs feel like one product. The risk is that customers mistake a simpler interface for a simpler financial relationship. ## The money needs somewhere to sit Custody means safeguarding assets for someone else. Payment orchestration means coordinating their movement. You can give excellent instructions to a moving company without owning the warehouse. You can also discover, during an incident, that the distinction matters quite a lot. Modern Treasury already has a practical software proposition. Its [developer guide](https://www.moderntreasury.com/ebooks/stablecoins-for-developers?ref=siliconsnark.com) describes a common set of building blocks for ordinary bank payments and stablecoins: accounts, counterparties, payment orders and records of incoming funds. A payment order is simply an instruction to move money. Reusing that structure means developers do not need a completely separate application just because one transfer uses a blockchain. Consider a hypothetical marketplace paying an overseas contractor. It might receive dollars, convert value into a supported stablecoin, send that token to a wallet, and match the transfer against its own accounting records. Alternatively, a recipient might need the token converted back into dollars and paid into a bank account. Every step needs a responsible operator, and every balance needs an explanation. A single interface can reduce the number of systems the marketplace has to reconcile. It cannot make the underlying obligations disappear. The finance team still needs to know who controls the assets, which transfer completed, and which party answers when it did not. ## A charter is a product decision with examiners attached The commercial logic, in my reading, is straightforward: the closer custody sits to payment operations, the more of a customer's financial workflow the provider can serve. That could make onboarding and incident handling easier. It could also make replacing the provider more complicated. That is a familiar tension in SiliconSnark's coverage of [stablecoins becoming business-account infrastructure](https://www.siliconsnark.com/stripe-turned-stablecoins-into-a-business-account-and-the-card-was-the-tell/). Convenience brings more activity into the same environment. More activity makes that environment harder to leave. Nobody needs to twirl a mustache; an integrated reconciliation workflow will do. There is a legitimate customer benefit here. A business evaluating custody wants a clear legal entity, defined responsibilities and a supervisor it can identify. A company pursuing a charter is volunteering for a more consequential relationship with the regulator than merely mentioning compliance on its homepage. But the eventual value depends on the authorized services, operating arrangements and customer terms. A charter application cannot tell a buyer whether the finished service will be cheaper, whether support will be good, or how an outage will be handled. Those are product questions that paperwork alone cannot answer. ## The regulatory queue has company, and opposition The route itself is established enough to have both precedents and critics. On December 12, 2025, the [OCC announced conditional approvals for five national trust bank applications](https://www.occ.gov/news-issuances/news-releases/2025/nr-occ-2025-125.html?ref=siliconsnark.com), including digital asset businesses. Conditional approval still required those applicants to meet the agency's conditions. That precedent should not be read as a prediction about this application. In a [final rule published March 2, 2026](https://www.occ.gov/news-issuances/federal-register/2026/91fr9977.pdf?ref=siliconsnark.com), the OCC changed its chartering regulation to track statutory language about trust company operations and related activities. The agency said it would assess authority for proposed activities case by case. The banking lobby disputes the breadth of that approach. ICBA's [October 2 lawsuit announcement](https://www.banklocally.com/web/guest/w/occ-release-oct-2026?ref=siliconsnark.com) argues that the OCC has exceeded its authority by permitting substantial non-fiduciary activity under national trust charters. That is the association's allegation, not a judicial finding, and it predates today's Modern Treasury announcement. This is the less photogenic side of the [stablecoin industry's charter queue](https://www.siliconsnark.com/stablecoin-founders-keep-applying-for-bank-charters-because-apparently-the-endgame-was-banking-all-along/): a fight over the scope of permissible banking activity. The logo on the application does not settle it. ## The API cannot reverse your enthusiasm Modern Treasury's current [stablecoin documentation](https://docs.moderntreasury.com/payments/docs/stablecoins?ref=siliconsnark.com) lists sending as supported and reversible sending as unsupported. It also specifies which tokens work on which networks. Those are existing product characteristics, not promised features of the proposed bank. For a customer, that means the payment control process deserves at least as much attention as the launch presentation. An employee approving an incorrect wallet address does not become less incorrect because the surrounding interface is polished. Asset custody and transaction authorization solve related but different problems. We encountered the same tension in [stablecoins becoming another checkout option](https://www.siliconsnark.com/coinbase-and-ppro-turn-stablecoins-into-just-another-checkout-button/): familiar software can conceal unfamiliar payment behavior. The better the abstraction, the more carefully the exception paths need to be explained. Buyers should ask how assets are segregated, who can authorize transfers, how recovery works, and which entity owes them which service. They should also compare the complete cost of a payment: custody, conversion, transfer and the recipient's access to usable money. A fast middle step is valuable. It is not the entire journey. ## The valuable feature is responsibility The broader pattern is the one explored in our [guide to stablecoin infrastructure economics](https://www.siliconsnark.com/deep-dive-stablecoins-turned-dollars-into-software-now-everyone-wants-the-toll-booth/): the opportunity extends beyond creating a token to controlling the services that make it useful. Modern Treasury's proposal fits that pattern with unusual clarity. My test for the eventual product would be whether customers gain a more understandable chain of responsibility, alongside fewer operational handoffs. That would be worth paying for. Merely putting more financial functions behind the same login would be less impressive. For now, the application is a statement of intent. The useful ambition is to make the time between “send payment” and “payment accounted for” less mysterious. The next great financial interface may still look like a dashboard. Behind it, someone has to be willing—and authorized—to hold the money.