The Bend company behind programmable money movement
Increase is the banking-infrastructure business associated with Bend, Oregon and founder Darragh Buckley. Y Combinator identifies it as founded in 2020, part of its Summer 2020 batch and located in Bend. Its customers build financial products using APIs that expose accounts, transfers and payment-network events. The relevant company is Increase Technologies, Inc., rather than an unrelated business sharing the ordinary English word. [1][6]
A major July 2026 change makes an older shorthand incomplete. Increase announced Increase Bank on July 29, describing an API-first bank using its core technology. Yet its current legal disclosures still distinguish the non-bank technology company from the banks supplying regulated services. The right description therefore depends on the legal entity: Increase Technologies is not a bank, while Increase Bank is a separately named regulated bank. Treating the entire brand as either only software or one universal bank would obscure the actual contracts. [2][3][22]
A bank launch does not erase the partner model
As of the October 4 review, the published partner list names Increase Bank, Grasshopper Bank, N.A., First Internet Bank of Indiana and Core Bank. Washington's Department of Financial Institutions separately lists Increase Bank among state-chartered commercial banks, at a Longview, Washington address. The bank account agreement updated September 29 identifies Increase Bank as a Washington state-chartered, FDIC-member bank. Its location should not be confused with the technology company's Bend identity. [3][4][5]
Analysis: the legal counterparty determines whose balance sheet holds a deposit, which agreement controls the account and which institution performs bank functions. A common interface can route different programs to different institutions without making those institutions interchangeable. The launch announcement says existing bank partnerships remain important. No ownership percentage, consolidated group financial statement or bank acquisition consideration is established here from marketing language alone. The verified change is the new bank offering and continuing multi-bank disclosures, not an invented complete corporate family tree. [2]
What an API-first core changes
The July 22 technology terms describe an API and dashboard through which users communicate instructions to bank partners, with separate bank agreements governing bank services. Analysis: this separates the software access contract from the deposit and payment contract. An application can create a transfer request quickly, while a bank and a payment network still determine its processing, eligibility and settlement. The software interface does not by itself grant unrestricted access to every banking function. [6]
Increase's documentation covers ACH, wires, checks, FedNow, Real-Time Payments, cards and push-to-card transfers. Its design gives software developers detailed objects and event states rather than reducing every transfer to a single completed-or-failed indicator. That is useful when a payroll run, insurance payment or supplier disbursement must be reconciled precisely. Analysis: the tradeoff is that the customer application retains meaningful responsibility for interpreting those states. A detailed API gives more control, but the integration still needs to model the underlying financial process correctly. [21]
Accounts are not the same as account numbers
Increase separates an Account, which represents funds held with a bank partner, from an Account Number that points to it. Multiple numbers can reference one account, allowing a platform to distinguish incoming funds by customer, vendor or use case. The documentation describes both demand-deposit and custodial for-benefit-of structures, subject to bank approval, and requires each account to be associated with an Entity and Program. [7]
Analysis: this design can simplify reconciliation without making every identifier a separate legal deposit account. Ten virtual identifiers pointing to one pool do not automatically create ten separate deposit-insurance entitlements. Similarly, an application ledger naming a customer is not a substitute for complete bank and beneficial-owner records. The operational advantage lies in associating payments with the correct obligation and controlling where money may move. The legal and insurance consequences still depend on actual account ownership, records, bank terms and applicable rules.
A payment instruction and a ledger entry tell different stories
The documentation distinguishes immutable Transactions from stateful Transfers. A Transfer progresses through a lifecycle and can create multiple Transactions. Pending Transactions represent potential debits or credits, including card authorizations and funds holds, and affect available balance without necessarily changing current balance. This makes visible a distinction that is often hidden in consumer interfaces: money can be reserved, submitted or settled at different times. [8]
Analysis: a platform that treats submission as final payment can tell a customer the wrong thing or release money too early. Conversely, treating every pending item as a completed debit can misstate an accounting balance. These are not merely technical naming issues. They shape whether a merchant receives a duplicate payment, whether a payroll exception is noticed and whether a reconciliation ledger agrees with the bank. Increase's explicit states supply the raw material for accurate operation; they do not guarantee that every customer has implemented those states correctly.
ACH exposes the difference between speed and finality
Increase's ACH-debit guide says a debit has no positive acknowledgment comparable to a guaranteed final collection: the receiving bank sends a return if it rejects the transfer. The company places holds against funds received through ACH debit, and the documentation distinguishes those held amounts from spendable available balances. Common return causes include insufficient funds, incorrect account information and missing authorization. It also describes a reserve-account arrangement as a possible route to faster availability. [9]
Analysis: early availability transfers timing risk rather than making it disappear. If a platform releases collected money before the return risk has resolved, some party must fund a later shortfall. A reserve, delayed availability or credit arrangement addresses that exposure in different ways. Faster payout can be commercially attractive, but its economics depend on fraud, return rates and recovery performance. Neither a low API latency nor a successful HTTP response measures whether the underlying collection will remain good.
Instant rails have their own constraints
FedNow and The Clearing House's RTP network provide credit-push payments that can settle in seconds outside traditional business hours. Increase's FedNow documentation says a settled transfer cannot be reversed through Increase, and notes that its API does not currently expose the network's request-for-return message or support FedNow Request for Payment. The RTP documentation describes Request for Payment support, with the payer authorizing the resulting push. Product support is therefore not identical across the two instant networks. [10][11]
Analysis: instant settlement is useful precisely because the recipient can rely on funds quickly, but that reduces the time available to stop a mistaken or fraudulent instruction. Reachability, and recipient validation remain material. An application may need a different rail when the receiving institution is not reachable; a fallback also changes timing and possibly cost. The absence of an ordinary reversal mechanism does not mean a recipient can never voluntarily return funds. It means a completed push is not equivalent to a card authorization that can simply be voided.
Reliable integration includes recovery from uncertain responses
Increase supports idempotency keys for creation requests. Repeating a request with the same key and arguments returns the previously created object; reusing a key with different request arguments produces a conflict. The design allows a customer to retry after a temporary error without necessarily creating a second transfer. This is important because a network timeout can leave the application uncertain whether the first request reached the server. [12]
Its webhook guide also makes delivery limits explicit. Production delivery can be attempted up to eight times, with the final retry around 72 hours, while Events remain available for 30 days through the API. The documentation warns that duplicate delivery is possible and describes polling as a recovery path after missed notifications. Analysis: end-to-end reliability includes the customer's event storage, deduplication and recovery behavior, not just Increase's uptime. A healthy infrastructure service cannot update an application that silently discards or misinterprets its events. [13]
Compliance is a division of work, not a removed obligation
Under Increase's managed-compliance model, the bank performs key Bank Secrecy Act and anti-money-laundering functions, including identity verification, sanctions screening and transaction monitoring. The platform still supplies customer information, helps resolve review questions and handles responsibilities such as customer support, fraud monitoring, information security and marketing. Managed therefore has a defined scope; it does not mean that a platform has no operational or conduct responsibilities. [14]
Under customized compliance, the platform maintains its own program and supporting controls, while the bank reviews documentation, supervises activity and conducts periodic reviews. The public materials describe evidence submission for identity verification and monitoring alerts. Analysis: this arrangement may fit sophisticated customers seeking greater control, but customization also creates more implementation and staffing work. The two models are commercial and operational choices within bank oversight. They should not be interpreted as a regulatory exemption, or as proof that a particular customer deployment satisfies every law that could apply to it. [15]
Pricing reveals transaction mechanics, not overall profitability
Increase's public technology fee page lists, among other charges, $0.50 for next-day ACH origination, $2 for same-day ACH, $15 for wire origination and $2.50 for RTP or FedNow origination. It also lists separate return and dispute charges. Monthly fees vary by use case, and the page invites custom pricing for financial-technology platforms moving customer funds and businesses with large balances. These are public list prices as reviewed October 4, not a representation of every negotiated contract. [16]
Analysis: the economic unit is a program's complete mix of accounts, transactions, exceptions, balances and support needs. A low-cost ACH transfer may be accompanied by a costly unauthorized return; a high-volume platform can negotiate terms unlike a small direct customer. Bank economics and technology-company economics also differ. Deposit funding, interest, credit exposure and network expenses need not accrue to the same legal entity as an API fee. No disclosed current financial statements in this review permit a verified consolidated margin, take rate, revenue or valuation estimate.
Scale claims and resilience evidence answer different questions
The homepage reports more than $500 billion in annualized transaction volume, over nine million API calls per day and 99.9999% historical uptime. These are company-reported measures. The page does not supply a complete measurement window and denominator for the uptime claim, nor enough detail to reconcile transaction volume to revenue. API calls include operations other than payments, and annualized volume is not the same as an audited fiscal-year total. [20]
The reliability guide provides more concrete architectural detail: Google Cloud in Oregon across multiple zones, high-availability database configuration, multi-region backups, daily restoration tests and redundant physical network connections in a Seattle colocation facility. It describes business-continuity and disaster-recovery plans. Analysis: those controls address identifiable failure modes, but multi-zone operation and backups do not establish uninterrupted service under every regional or counterparty outage. Architecture and test claims are evidence of design choices; observed incident history, recovery outcomes and contractual commitments answer different resilience questions. [17]
Security assurance has a defined scope
Increase says it undergoes annual PCI DSS assessment as a Level I service provider and annual SOC 2 audits, with links to assurance materials. Its security page describes disk-level encryption, additional application-level encryption for some sensitive fields, HTTPS enforcement and the option to restrict API access by IP address. These are stated controls and assessment disclosures, rather than a guarantee that no compromise or user-side failure can occur. [18]
Analysis: payment infrastructure is particularly sensitive to credentials, privilege and instruction integrity. A correctly authenticated but fraudulently induced instruction can still move money to the wrong destination. Audit reports evaluate a defined scope and period; they are not approval of every downstream application. The platform's own permissions, approval logic, vendor changes and incident handling remain relevant even when the underlying provider has mature controls. In that sense, information security and payment authorization are linked operational problems with different evidence requirements.
Tekion shows how infrastructure becomes an industry product
On October 1, 2026, Increase announced Tekion Spend with Tekion and Core Bank inside Automotive Retail Cloud, with availability to U.S. ARC dealerships beginning in the fourth quarter. The announcement says ARC serves more than 2,000 dealerships and describes named bank accounts, payments and reconciliation within dealership software. It also says an initial prototype was built on Increase APIs in under three weeks. The dealership count is the stated reach of ARC, not a verified count of live Tekion Spend banking customers. Prototype speed is not the duration of a fully approved production rollout. [19]
Analysis: the example explains Increase's position in the value chain. The dealership interacts with familiar operating software; the technology layer connects records and payment instructions; the bank supplies regulated account services. This can reduce the separation between an invoice, the payment and the accounting entry. The commercial opportunity comes from making that combination repeatable across industries, while each industry brings its own counterparties, payment patterns and exceptions. A successful launch announcement establishes a product and relationship, not yet long-run adoption or measured financial benefit.
The enduring question is end-to-end execution
The current legal disclosures state that eligible deposits at partner banks receive FDIC coverage up to applicable limits and that insurance protects against failure of an insured bank. That protection does not turn technology downtime, fraud or reconciliation errors into insured bank failures. The account relationship and the software relationship remain distinguishable even when customers experience one brand. [5]
Increase's most distinctive proposition is detailed, programmable access to banking operations, now accompanied by a bank carrying the Increase name and continued partner-bank relationships. Its public documentation is unusually useful for understanding money movement and failure handling. The unresolved commercial questions are less visible: current revenue, customer concentration, profitability, program-level returns and the precise ownership structure are not established by the materials reviewed. The business can be evaluated as a concrete infrastructure architecture and set of bank relationships without converting impressive processing volume into unsupported private-company financial performance.
Sources
- Y Combinator, Increase company profile, reviewed October 4, 2026SourceBack to text: ↑
- Increase, announcing Increase Bank, July 29, 2026SourceBack to text: ↑1↑2
- Increase, legal terms and partner-bank list, reviewed October 4, 2026SourceBack to text: ↑1↑2
- Washington DFI, list of Washington state-chartered banks, reviewed October 4, 2026Official sourceBack to text: ↑
- Increase Bank account agreement, updated September 29, 2026SourceBack to text: ↑1↑2
- Increase Technology Service Terms, updated July 22, 2026SourceBack to text: ↑1↑2
- Increase, accounts and account numbers documentation, reviewed October 4, 2026SourceBack to text: ↑
- Increase, transactions and transfers documentation, reviewed October 4, 2026SourceBack to text: ↑
- Increase, ACH debits and funds holds documentation, reviewed October 4, 2026SourceBack to text: ↑
- Increase, FedNow documentation, reviewed October 4, 2026SourceBack to text: ↑
- Increase, Real-Time Payments documentation, reviewed October 4, 2026SourceBack to text: ↑
- Increase, idempotency documentation, reviewed October 4, 2026SourceBack to text: ↑1↑2
- Increase, events and webhooks documentation, reviewed October 4, 2026SourceBack to text: ↑1↑2
- Increase, managed compliance documentation, reviewed October 4, 2026SourceBack to text: ↑
- Increase, customized compliance documentation, reviewed October 4, 2026SourceBack to text: ↑
- Increase, technology fees, reviewed October 4, 2026SourceBack to text: ↑
- Increase, reliability architecture documentation, reviewed October 4, 2026SourceBack to text: ↑
- Increase, security and audit disclosures, reviewed October 4, 2026SourceBack to text: ↑
- Increase, Tekion and Core Bank embedded banking launch, October 1, 2026SourceBack to text: ↑
- Increase homepage, company-reported scale metrics and product list, reviewed October 4, 2026SourceBack to text: ↑
- Increase, technical documentation index and supported products, reviewed October 4, 2026SourceBack to text: ↑
- Increase updates index, date of Increase Bank announcement, July 29, 2026SourceBack to text: ↑