- Increase and Column both give you direct access to bank rails without a BaaS aggregator in the middle, but they are built for different buyers.
- Column is a chartered bank with a full API surface: ACH, wires, FedNow, RTP, card issuing, and deposit accounts, all owned end-to-end.
- Increase is a payments-focused API layer that connects to multiple bank partners, prioritizing developer experience and payment operations over full banking primitives.
- The margin difference is structural: Column lets you capture more of the economics when you scale, but the compliance and relationship overhead is higher from day one.
- Neither is the right default. The choice turns on whether you need a programmable ledger or a programmable bank.
When evaluating Increase vs Column, the surface-level comparison, both skip BaaS aggregators, both offer direct bank rail access, obscures a more consequential difference in what each platform actually is. Column is a nationally chartered bank with a developer API, suited for teams that need full banking primitives and are ready to own the compliance relationship directly. Increase is a payments API that connects to bank partners, better suited for teams that want cleaner payment operations without building a banking product from scratch.
Why Are Builders Choosing Direct-Bank Infrastructure Over BaaS Aggregators?
The standard BaaS stack puts two or three intermediaries between your product and the underlying bank rails. You pay each one. A BaaS platform like Unit or Treasury Prime sits on top of a sponsor bank, takes a margin on interchange and transaction fees, and passes you a simplified API. That simplicity has a cost: less control over the ledger, less visibility into what the bank actually allows, and pricing that gets harder to defend as volume grows.
Direct-bank infrastructure removes at least one layer. Column removes all of them by being the bank. Increase removes the aggregator layer by connecting directly to its bank partners rather than wrapping another platform. Both models trade some of the hand-holding you get from a managed BaaS provider for more direct access to economics and configuration. If you want to understand the full economics of that trade-off, the hidden economics of Banking-as-a-Service lays out what each layer in the stack actually captures.
What Does Column Actually Offer as a Chartered Bank API?
Column holds a national bank charter, which means it is not a fintech riding on a sponsor bank. It is the sponsor bank. That distinction changes everything about what you can configure. Column’s API covers ACH origination and receipt, domestic and international wires, FedNow instant payments, RTP (The Clearing House’s real-time rails), card issuing, and deposit account creation. You are not asking a middleware layer whether the bank will allow a particular use case. You are asking the bank directly.
Column publishes its documentation publicly at docs.column.com, and the API reference is detailed enough to evaluate before a sales call. The developer experience reflects a product built API-first rather than retrofitted from a legacy core. Account structures, sub-ledgers, and transaction routing are all configurable at the API level.
The trade-off is compliance scope. When you build on Column, you are entering a direct banking relationship. Depending on your product, that means your compliance program needs to be more mature before you go live. Column reviews what you are building, and the onboarding process reflects that. It is not a self-serve sign-up.
What Does Increase Offer as a Payments API?
Increase describes itself as banking infrastructure for ambitious technology companies. Its API covers ACH, wires, check issuance, card creation, and real-time payments. Unlike Column, Increase is not a bank. It works with bank partners to give developers direct access to payment rails with minimal abstraction on top.
The Increase developer experience is notably clean. The API reference reads like it was written by engineers who had to use it themselves. Error messages are descriptive. Webhooks are well-structured. The product prioritizes payment operations: initiating, tracking, and reconciling transactions. If your product is about moving money reliably with good operational visibility, Increase is designed around that problem.
Increase does not offer card issuing at the same depth as Column, and it is not positioned as a full banking platform. It is better understood as a high-fidelity payments API with real bank connectivity underneath, rather than a tool for building a neobank or issuing FDIC-insured deposit products.
How Do the Rail Access Capabilities Compare Side by Side?
| Rail / Feature | Column | Increase |
|---|---|---|
| ACH origination | Yes (ODFI, direct) | Yes (via bank partners) |
| ACH receipt | Yes | Yes |
| Domestic wires | Yes | Yes |
| International wires (SWIFT) | Yes | Yes |
| FedNow instant payments | Yes | Yes |
| RTP (The Clearing House) | Yes | Yes |
| Card issuing | Yes (debit, commercial) | Limited / partner-dependent |
| Deposit accounts (FDIC) | Yes (Column is the bank) | Via bank partners |
| Programmable ledger | Yes | Yes |
| Self-serve onboarding | No (relationship-based) | More accessible |
| Publicly available pricing | Not disclosed | Not disclosed |
| Charter type | Nationally chartered bank | Not a bank (bank partners) |
Both platforms reach the major US payment rails. Where Column separates is in the deposit account layer and card issuing. Because Column is the bank, the accounts your users hold are Column accounts, FDIC-insured through Column’s own charter. That matters if you are building a product where the account relationship itself is part of your value proposition.
What Does the Fee Math Look Like at Scale?
Neither Column nor Increase publishes per-transaction pricing on a public pricing page. Both require you to go through a sales or application process to get quotes. That said, the structural economics differ in a way that matters as volume grows.
Consider a fintech processing $50 million per month in ACH volume. On a typical BaaS aggregator, you might pay a platform fee plus a per-transaction cost, and the aggregator captures a spread on top of what the underlying bank charges. On a direct-bank model like Column, you are negotiating directly with the bank. There is no aggregator margin between you and the cost of the rail. At that volume, even a few basis points of difference compounds into meaningful dollars annually. The hidden costs in fintech SaaS margins covers exactly how those aggregator spreads show up in ways founders miss at earlier stages.
Increase sits in an interesting middle position. It removes the aggregator layer, but it is not the bank, so there is still a bank partner in the chain. That means some economics flow to the bank partner. The exact split is not public. At moderate volumes, Increase likely prices competitively relative to traditional BaaS platforms. At very high volumes, Column’s model may offer better unit economics simply because the charter is in-house.
The FintechSpecs Control-vs-Convenience Spectrum
Most infrastructure comparisons treat control and convenience as vague trade-offs. Here is a more precise way to think about it: the FintechSpecs Control-vs-Convenience Spectrum maps fintech infrastructure choices across four dimensions: rail ownership, ledger configurability, compliance burden, and time-to-first-transaction.
On rail ownership, Column sits at maximum control. It owns the charter, the routing number, and the rail relationships. Increase owns the developer interface but relies on bank partners for the underlying rail access. On ledger configurability, both are high. On compliance burden, Column is higher from day one because you are dealing with a bank directly. On time-to-first-transaction, Increase is faster for most teams because the onboarding process is less intensive.
A team at a Series A company building an expense management tool for SMBs probably wants Increase: cleaner payment operations, faster to integrate, lower initial compliance overhead. A team building a neobank or an embedded banking product where the account itself is the product probably wants Column, because only Column lets you say your users’ deposits sit in a Column account under Column’s charter, not through a third party.
Who Should Build on Column?
Column fits teams building products where the banking relationship, not just the payment, is core to the value. That includes neobanks, embedded banking platforms for vertical SaaS, and any product that needs to issue deposit accounts under its own program. It also fits larger fintech companies that have outgrown BaaS aggregators and want to negotiate directly on economics. The direct relationship with a chartered bank is the point, not a feature.
Column also makes sense for teams that need card issuing alongside account creation. The ability to issue debit or commercial cards tied to Column accounts, all through the same API, removes a separate vendor relationship. For teams evaluating card-issuing platforms more broadly, the Marqeta vs Lithic vs Stripe Issuing comparison covers that category in more depth.
The downside is real: Column’s onboarding is selective and takes time. If you are three engineers and a prototype, Column will likely ask you to come back when the product is further along. That is not a knock on Column. It reflects what a direct bank relationship actually requires from both sides.
Who Should Build on Increase?
Increase fits teams that need high-quality payment operations without building a banking product. If your product moves money, and you want that money movement to be reliable, well-documented, and easy to reconcile, Increase is built around that specific need. The API is developer-first in a way that matters for integration speed. Teams with strong engineering resources but limited compliance bandwidth will find Increase more accessible than Column at early and mid stages.
Increase also fits companies where payment operations are a support function rather than the core product. A lending platform that needs to disburse loans and collect repayments via ACH is a good fit. A payroll tool that needs to push funds reliably is a good fit. You are not trying to become a bank. You are trying to move money with bank-level reliability. Increase is built for that. For a broader look at how ACH APIs compare in this category, the best ACH payment APIs for vertical SaaS covers the field.
How Do Column and Increase Compare on Developer Experience?
Both products invest heavily in developer experience relative to legacy bank APIs. Column’s documentation at docs.column.com is structured around concepts first, then API reference. Increase’s documentation is similarly well-organized, with clear error handling documentation and sandbox environments. Neither requires you to read 300 pages of PDF before writing your first API call.
Where they differ is in breadth. Column’s documentation covers more surface area because it is documenting a full bank: account creation, deposit operations, interest configuration, card controls, and compliance tooling. Increase’s documentation is tighter because the product scope is tighter. If your team needs to move fast and get to a working integration in days, Increase’s narrower scope is an advantage, not a limitation.
Frequently Asked Questions
Is Column a real bank?
Yes. Column holds a national bank charter, which means it is a regulated bank under federal oversight, not a fintech company riding on a sponsor bank’s charter. When you build on Column, your users’ accounts are Column bank accounts. Column has its own routing number and direct membership in the major US payment networks including FedNow, RTP, ACH, and the Fedwire system.
What does Increase do differently from a BaaS aggregator?
Increase connects directly to bank partners rather than sitting as a middleware layer on top of a BaaS platform. That removes one layer of abstraction and one layer of margin. A traditional BaaS aggregator takes a spread on transactions on top of what the bank charges. Increase positions itself as a direct connection to bank rails with a better developer interface, without the aggregator economics in the middle.
Can you use Column or Increase without a banking license?
For most use cases, yes. Column and Increase handle the bank regulatory layer. Depending on your product, you may need a money transmitter license or other state-level licensing, but you are not required to hold a bank charter to build on either platform. Your compliance requirements depend on what your product does with the accounts and payments, not on which infrastructure you use. The fintech compliance readiness checklist is a useful reference for mapping your specific obligations.
Does Column issue its own routing number?
Yes. Because Column is a nationally chartered bank with direct membership in ACH, Fedwire, FedNow, and RTP, it operates under its own routing number. That is meaningfully different from most BaaS platforms, where the routing number belongs to the underlying sponsor bank rather than the platform you are building on. When you create accounts through Column’s API, those accounts route through Column’s own banking infrastructure. Increase, by contrast, routes through its bank partners’ routing numbers, since Increase itself is not a chartered bank.
How does Column’s revenue compare to Increase?
Column does not publicly disclose revenue. Sacra, a private company research firm, has published estimates of Column’s revenue trajectory, though those figures are analyst estimates rather than confirmed disclosures. Column has raised venture funding and publicly describes itself as scaling its banking-as-a-platform model, but the split between interest income and API fee revenue is not broken out in any public filing. Increase similarly does not publish revenue figures. For both companies, scale signals are more reliably read through their customer lists and product roadmap activity than through financial disclosures.
What happens if you outgrow Increase?
Teams that outgrow Increase typically migrate toward Column or toward building their own bank partnership directly. The migration path is not trivial: account numbers, payment flows, and reconciliation logic all need to be rebuilt. Planning your infrastructure ceiling before you hit it is worth the effort. The critical mistakes when choosing fintech infrastructure covers exactly this kind of lock-in risk in more detail.
Are there alternatives to both Column and Increase?
Yes. Modern Treasury is a closely related option focused on payment operations and reconciliation, though it does not hold a bank charter. Stripe Treasury offers embedded financial accounts through a managed partnership model. Unit and Treasury Prime offer more managed BaaS with sponsor bank relationships. For a broader view of the direct-bank and BaaS category, the best BaaS platforms for fintech startups maps the full field.
The Actual Decision Framework
Strip out the feature lists and the comparison tables. The real question is simpler: are you building a banking product, or are you building a product that needs payments?
If the account is the product, if users need to hold money in an account your platform controls, if card issuing is part of your core experience, Column is the right direction. Accept the longer onboarding, build the compliance program, and get the economics that come with being one step from the charter.
If payments are infrastructure underneath something else, if you need ACH and wires to work cleanly so your core product can do its job, Increase is the right direction. The developer experience is tight, the integration is faster, and the compliance lift is lower at the start. You will pay for that convenience in margin at high volumes, but for most teams, that trade is worth it until the volumes make renegotiation worthwhile.
The deeper insight in the Increase vs Column comparison is that the BaaS aggregator is not the only alternative to building your own bank. Both Column and Increase represent a middle path that most fintech teams overlook. Direct-bank infrastructure is not a niche choice anymore. It is the direction the market is moving, and the two companies doing it best happen to be doing it differently enough that choosing between them is a real strategic decision, not a coin flip.
