- Modern Treasury is a payment operations layer that sits on top of your existing bank relationship. Increase is a chartered bank that delivers its own balance sheet and rails directly through an API.
- The architectural difference matters more than the feature list: with Increase, you hold accounts at the bank itself. With Modern Treasury, you hold accounts at a partner bank and use Modern Treasury to orchestrate them.
- Teams that need multi-bank orchestration, a built-in ledger, and workflow automation lean toward Modern Treasury. Teams that want direct rail control and a single bank relationship with no middleware lean toward Increase.
- Compliance posture differs sharply: Increase gives you a direct bank counterparty for ACH, wire, and RTP origination. Modern Treasury routes through whichever bank it partners with, which adds a layer to your vendor risk stack.
- Neither platform publicly lists per-transaction pricing. Both require a sales or onboarding conversation to get figures.
Modern Treasury is a software orchestration layer for payment operations, sitting above one or more bank accounts to automate ACH, wire, RTP, and FedNow flows alongside a built-in ledger. Increase is a chartered bank with a full API, meaning your application opens accounts and originates payments directly at the bank, with no middleware between your code and the rails. The right choice depends on whether you need multi-bank orchestration or direct bank access with fewer moving parts.
What Is the Actual Architectural Difference Between Modern Treasury and Increase?
Most teams framing this as “ACH wrapper A vs ACH wrapper B” are missing the structural point. The two products occupy different positions in the payment stack.
Modern Treasury is payment operations software. It connects to bank accounts you already hold, or to accounts held at its partner banks, and then provides a unified API for initiating and tracking money movement across ACH, wires, RTP, FedNow, and check. It also handles counterparty management, reconciliation, and a double-entry ledger. Modern Treasury does not hold a banking license. The bank relationship exists between you and the underlying partner bank.
Increase is a different animal. Increase is itself a chartered bank, regulated by the OCC. When you build on Increase’s API, you are opening accounts directly at Increase and originating payments over rails Increase itself participates in. There is no intermediary bank relationship to manage on your side. You have one counterparty: Increase.
That difference propagates through compliance, fault tolerance, and how you scale. With Modern Treasury, your ACH origination agreement, wire agreements, and real-time payment access all sit with the partner bank. If that bank relationship changes, your rails change. With Increase, the bank is the vendor.
How Does Each Platform Handle ACH and Wire Origination?
Both platforms support ACH credits and debits, domestic wires, and real-time rails including RTP. But the origination path differs in ways that matter at audit time.
On Increase, you originate ACH as a customer of a chartered bank. Your company is the Originator, Increase is the ODFI, and the relationship is direct. There is no BaaS middleware, no program manager sitting between you and the bank, and no sponsor bank agreement to maintain separately. According to Increase’s public documentation, the platform supports ACH, wires, check deposits, RTP, and card issuance, all through the same API surface.
On Modern Treasury, ACH origination runs through whichever bank Modern Treasury has connected you to. Modern Treasury’s own documentation describes it as a software layer on top of your bank account. If you bring your own bank, Modern Treasury connects via that bank’s API or file-based integration. If you use a Modern Treasury-managed bank relationship, you are effectively in a program managed by Modern Treasury at a partner institution. Either way, there is a bank behind the scenes that is the actual ODFI.
For wire origination, Modern Treasury supports both domestic and international wires through its connected bank accounts. Increase supports domestic wires natively. Teams with significant cross-border wire volume should verify international wire coverage directly with each vendor before committing.
Which Platform Owns the Bank Relationship, and Why Does That Matter?
This is the question that separates a thoughtful infrastructure decision from one that causes pain eighteen months later.
With Increase, your company is a direct customer of a chartered bank. Your accounts, your ODFI agreements, your exposure to rail-level changes are all visible and documented in a single relationship. If Increase changes a fee or a policy, you get notice as a bank customer. If you ever want to migrate, you know exactly what you are moving: accounts at one bank.
With Modern Treasury, the bank relationship sits one level down. Modern Treasury is your contractual counterparty for the software. The bank behind it is Modern Treasury’s counterparty, or yours separately if you bring your own bank. This creates a layered vendor risk structure. Your compliance and operational readiness needs to account for two vendors, not one: Modern Treasury for orchestration and the underlying bank for the actual rail access.
For teams building regulated products, this matters in vendor due diligence. A bank examiner or a sophisticated enterprise customer asking for your third-party risk documentation will see two critical vendors where Increase users see one. That is not automatically a disqualifier for Modern Treasury, but it is a real operational difference.
What Does Modern Treasury’s Ledger Capability Add That Increase Does Not?
Modern Treasury’s most differentiated feature is its built-in financial ledger. This is not a transaction log. It is a double-entry accounting system that tracks expected versus actual payment states, manages counterparty balances, and lets you model internal money movement without those transactions hitting bank rails.
Consider a company running a marketplace where merchants earn funds over time and request payouts on demand. Modern Treasury’s ledger lets that company track virtual balances across merchants in the same system that manages actual ACH payouts. The ledger and the payment engine share a single data model. Reconciliation becomes a query against your own ledger rather than a reconciliation against bank statements.
Increase does not offer a built-in ledger in the same sense. Increase is the bank layer: accounts, balances, transactions, and rails. If you need a ledger abstraction above that, you build it yourself or add a tool like a dedicated fintech ledger platform on top of Increase. That is more infrastructure to manage, but it also gives you more control over your data model.
Teams building embedded finance products, payroll platforms, or multi-sided marketplaces where virtual balance tracking is core to the product will find Modern Treasury’s ledger saves significant engineering time. Teams that only need clean, direct rail access and will manage their own accounting separately will find Increase’s simplicity more appealing.
How Do Modern Treasury and Increase Compare on Developer Experience?
Both platforms are genuinely API-first. The quality gap between them and legacy payment infrastructure is large. The gap between them is narrower and depends on what your team is actually building.
Increase’s API is designed around the primitives of banking: accounts, transactions, transfers, entities, and cards. The documentation is precise and the object model maps directly to how the underlying rails work. Developers who want to reason about what is actually happening at the bank level will find Increase’s API transparent in a way that feels unusual for this space. There is less abstraction, which means fewer surprises but also more work to build orchestration logic yourself.
Modern Treasury’s API adds orchestration primitives on top of the banking layer: payment orders, expected payments, counterparties, and ledger accounts. For teams that want the framework pre-built, Modern Treasury’s API reduces the surface area their engineers need to handle. The tradeoff is that you are working at a higher level of abstraction, which can make debugging harder when something at the bank level behaves unexpectedly.
Modern Treasury also ships workflow tools like approval policies, user roles, and notification routing that make it useful for teams where non-engineers need to interact with payment operations. Increase is squarely an engineering tool with no equivalent workflow layer built in.
Modern Treasury vs Increase: Side-by-Side Feature Comparison
| Dimension | Modern Treasury | Increase |
|---|---|---|
| Entity type | Payment operations software company | Chartered bank (OCC-regulated) |
| Bank relationship holder | Partner bank (or your own bank) | Increase itself |
| ACH origination | Yes, via partner or connected bank | Yes, direct (Increase is ODFI) |
| Wire transfers | Yes, domestic and international | Yes, domestic |
| RTP and FedNow | Yes | Yes |
| Built-in double-entry ledger | Yes, native | No (build your own or add a tool) |
| Card issuance | No native card product | Yes, debit card issuance via API |
| Counterparty management | Yes, with KYC/KYB verification | Entity management via API |
| Multi-bank support | Yes, core differentiator | No (single bank: Increase) |
| Workflow and approval tools | Yes | No |
| Sandbox environment | Yes | Yes |
| Public pricing | Not published | Not published |
| Primary user | Engineering and finance/ops teams | Engineering teams |
Who Should Use Modern Treasury and Who Should Use Increase?
The answer comes from matching your architectural needs to each product’s actual model, not from comparing feature checkboxes.
Build on Modern Treasury if:
- You need to orchestrate payments across multiple banks and want a single API regardless of which bank executes the transaction.
- You are building a product where internal balance tracking, virtual accounts, or multi-party ledgering is part of your core feature set.
- Your ops or finance team needs to review, approve, or modify payments without writing code. Modern Treasury’s workflow layer handles this without custom tooling.
- You are bringing an existing bank relationship and need software to sit on top of it, not a new bank.
Build on Increase if:
- You want the simplest possible vendor stack: one API, one bank, no middleware layer to manage separately.
- Your compliance team wants to minimize third-party vendor risk and prefers a direct bank relationship over a software-plus-bank arrangement.
- You need card issuance alongside ACH and wire, all under one roof.
- Your team is engineering-led and comfortable building any orchestration or ledger logic you need on top of a clean banking API.
The FintechSpecs Bank Relationship Test is a useful mental model here: ask yourself whether you want to own the bank relationship or rent access to one through software. Increase gives you ownership. Modern Treasury gives you access, with orchestration built on top. Neither answer is wrong, but they produce different compliance profiles, different vendor concentrations, and different migration paths if you ever need to change course.
What Does Pricing Look Like for Modern Treasury vs Increase?
Neither company publishes per-transaction or monthly fees on their public-facing pages. Both require you to contact sales to get a quote. This is standard for infrastructure vendors at this level, where pricing depends on transaction volume, rail mix, and contract terms.
For budgeting purposes, both platforms typically sit in the category of enterprise infrastructure with monthly platform fees plus per-transaction fees, with volume discounts negotiated at contract time. The hidden cost to account for with Modern Treasury is the potential for fees at both the Modern Treasury layer and the underlying bank layer. Increase has a single fee structure because it is the bank. Teams tracking the hidden costs inside fintech infrastructure will want to model both layers explicitly when comparing total cost.
Do I Need Modern Treasury or Can I Go Direct With Increase?
This is the right question, and the answer is structural rather than preferential.
If your payment operations involve a single bank and your engineering team is comfortable building the workflow and ledger logic themselves, Increase gives you everything you need at fewer layers. You get direct bank access, clean rail support, and an API built by people who clearly understand what developers actually need from a banking interface.
If you need to spread payment volume across multiple bank relationships for redundancy, regulatory reasons, or because different rails are available at different banks, Modern Treasury’s orchestration model is necessary. A single bank API cannot solve multi-bank routing. Modern Treasury can. That capability is also relevant for larger companies that have negotiated their own bank agreements and need software to sit on top of them. For teams mapping out their full fintech infrastructure stack, this layer distinction belongs in your architecture diagram from day one.
The honest answer for early-stage teams: if you are at seed or Series A and moving money through a single set of rails, Increase is probably the cleaner starting point. You avoid introducing a software intermediary and get direct bank accountability. If you are at Series B or beyond, running high volumes across varied payment types, or building a product where multi-bank resilience is a selling point to your own customers, Modern Treasury’s orchestration layer earns its cost.
How Does the Bank-Relationship Model Affect Compliance and Scaling?
Compliance is where the bank relationship model stops being an architectural abstraction and becomes a concrete operational problem.
With Increase, your company’s BSA/AML program interfaces directly with a chartered bank. Your NACHA compliance for ACH origination is documented in your agreement with Increase as the ODFI. When your volume grows or your product changes, you have a single counterparty to negotiate with. When a regulator asks who your bank is, the answer is one sentence.
With Modern Treasury, the picture is layered. Modern Treasury handles payment orchestration. The underlying bank handles rail access and the bank-level compliance obligations. If Modern Treasury uses a partner bank that itself operates under a sponsor bank model, there can be three entities in the chain: your company, Modern Treasury, the partner bank, and potentially a sponsor bank above that. This is not hypothetical for fintech platforms. It is a real structure that shows up in vendor risk reviews. The economics of banking-as-a-service arrangements mean each layer takes margin and adds agreement surface area.
As volume scales, the difference between managing one bank relationship and managing a software vendor plus a bank becomes meaningful in legal, compliance, and finance overhead. Teams that plan to process hundreds of millions of dollars annually, or that serve regulated end customers, should model this compliance cost explicitly before choosing their infrastructure path.
Frequently Asked Questions
Is Modern Treasury a bank?
No. Modern Treasury is a payment operations software company. It provides APIs and workflow tools for initiating and tracking payments, but it does not hold a banking license. The bank relationship sits with Modern Treasury’s partner bank or with the bank your company connects to through Modern Treasury’s platform. Modern Treasury’s own documentation describes it as a software layer on top of your bank account.
Is Increase a BaaS platform?
Increase is a chartered bank, regulated by the OCC, that delivers its services through an API. This is different from a Banking-as-a-Service platform, which typically involves a technology company sitting in front of a sponsor bank. With Increase, the API and the bank are the same entity. You are a customer of the bank directly, not of a program manager who contracts with a bank on your behalf.
Can I use Modern Treasury with Increase?
Yes. Modern Treasury’s own documentation explicitly describes it as a software layer on top of a bank account at Increase. This means you can use Increase as the bank layer for direct rail access while using Modern Treasury’s orchestration, ledger, and workflow tools on top. This combination gives you the bank-ownership benefits of Increase with the payment operations tooling of Modern Treasury, at the cost of paying for both platforms.
Which platform is better for ACH at high volume?
For raw ACH throughput with a single bank, Increase’s direct origination model is architecturally cleaner because there is no middleware between your application and the ODFI. For high-volume ACH spread across multiple banks for redundancy or regulatory reasons, Modern Treasury’s multi-bank orchestration becomes necessary. Volume alone does not decide this. Your bank strategy does.
Does Modern Treasury support RTP and FedNow?
Yes. Modern Treasury publicly lists support for RTP and FedNow alongside ACH, wire, and check. Access to real-time rails depends on the underlying bank in your Modern Treasury setup having those rail connections, so verify with Modern Treasury during onboarding which rails are available through your specific bank configuration.
What happens to my payment operations if my vendor relationship changes?
With Increase, a vendor relationship change means migrating bank accounts at a chartered bank, which is a significant but defined operation. With Modern Treasury, a change could affect either the software layer or the underlying bank, and the migration scope depends on which is changing. Teams building at scale should review the common fintech infrastructure mistakes around vendor lock-in before committing to either model.
Do either of these platforms support international payments?
Modern Treasury supports international wires through its connected bank accounts. Increase’s public documentation focuses on US-based rails. For companies with significant cross-border payment volume, Modern Treasury has a broader stated feature set, but the specific corridors available depend on your bank configuration. Verify international rail coverage directly with both vendors before treating this as a deciding factor.
The Architecture Decision That Follows You
The choice between Modern Treasury and Increase is not primarily about which product has a better API. Both have genuinely good developer experiences. The choice is about where you want the bank relationship to live in your stack, and what that implies for your compliance posture, your vendor risk surface, and your ability to change direction later.
Increase is an unusual thing in fintech infrastructure: a bank that decided to compete on developer experience. That gives teams who build on it something most API-first payment companies cannot offer, a single, direct, regulated bank counterparty with no program manager or middleware in the chain. Modern Treasury took a different bet, that what companies actually need is not another bank but a smarter orchestration layer that works with whatever banks already exist. Both bets are defensible. They are just different bets.
The mental model worth carrying: if your payments architecture diagram has only one bank in it, Increase likely gives you more with less. If your diagram has multiple banks, or needs a ledger as a first-class product feature, Modern Treasury earns its position in the stack. Pick based on your architecture, not your feature wishlist.
