Increase Updates

Announcing Increase Bank

Darragh Buckley — Wed, 29 Jul 2026 00:00:00 GMT

I’m excited to announce the launch of Increase Bank.

This is the bank for ambitious technology companies. You’re obsessed with building the best possible product for your customers; we’re just as obsessed with building for you.

A bank sits between you and payment rails like ACH, wires, and Visa. Those rails can handle just about anything you want to do programmatically, but the core technology inside most banks prevents you from harnessing that capability.

Increase built our own API-first core technology from scratch.

Everything is programmable, with minimal human intervention even for edge cases. Whenever possible, we want your machines to talk to our machines.

Our APIs are faithful. We pass through high-fidelity data straight from the payment rails. We make as few decisions on your behalf as possible. If that appeals to you, here’s our documentation.

Companies like Gusto, Ramp, and Stripe already rely on Increase core technology to process more than $500B annually.

Since 2020, Increase has been the banking backbone to move, store, and lend money at scale. We’ve helped our customers build regulated banking products with support from some fantastic bank partners. Those partnerships remain important.

But we’re still early in the grand scheme; we will get much bigger. Today, we take the next step toward that future.

This is the bank I needed at Stripe.

Before starting Increase, I was the first employee at Stripe. When we worked with banks, they often struggled to understand what we needed and why it mattered. Problems that seemed minor to them—like managing wires over email—were blockers for us. We had to build all kinds of workarounds.

For years, I needed a bank with good product sense. One that grasped the possibilities of software and couldn’t stand to see them stifled.

The Increase team comes from industry-leading payments companies, and we’ve all had similar frustrations and hopes. We’re motivated to get this right.

We believe the future of banking is API-first.

Companies use Increase to pay millions of people on time, free up working capital for small businesses, and simplify healthcare billing.

I’m inspired by the people who create these new financial technologies, but they’re not the only ones depending on banks. In a real way, you can’t build a road, school, company, spacecraft, hospital, corner store, or country without a bank.

Banks are where we formalize trust to do ambitious things together. An institution this important should run on the best technology we can build.

That’s why Increase Bank exists.

2026 Q2 Newsletter

Fri, 24 Jul 2026 00:00:00 GMT

Here’s what we shipped in the second quarter of 2026.

Money movement

We launched managed compliance for platforms. In this model, you can delegate identity verification and transaction monitoring to Increase and our bank partners instead of running them yourself. This makes launching a new product and program faster and easier than ever before on Increase, while preserving the optionality to graduate to sponsor banking as you grow.
Blockchain transfers are now in beta. Send and receive USDC from an Increase account, Increase handles the conversion to/from USD to stablecoin for you in minutes.
FedNow is live for all users. FedNow enables real-time clearing and settlement of domestic transactions within seconds, 24/7, directly through the Federal Reserve.

Things we wrote and said

We shared insights into the way Vantaca uses Increase to power its Vendor Pay solution.
Matt Hennessy from Increase and Jamie Fox from Tekion joined the Fintech One-on-One podcast, hosted by Peter Renton, to discuss how embedded finance is helping to fuel growth for vertical fintechs.
We wrote about merchant category codes, the four-digit numbers that classify the type of goods or services a business offers.

Looking ahead

Up next we’re building out our cross-border payments and lending APIs. Let us know if you’re interested in trying them out!

Canary transfers: testing banking infrastructure in production

Mattt Zmuda — Fri, 17 Jul 2026 00:00:00 GMT

There’s a saying in software: reality has a surprising amount of detail.

The Federal Reserve documents exactly when wire transfers are supposed to settle. What the manual won’t tell you is that during a major Amazon Web Services outage, the Fed might stay open an hour late to give banks more time to finish their daily settlements. We noticed because our own wires settled faster than expected. That’s the kind of detail you only discover by exercising the banking system in production, every minute of every day.

At Increase, we connect directly to the Federal Reserve and Visa, which means their surprises are ours to catch. Prevention handles the failures you anticipate. For everything else, the goal is to shrink the time between a failure happening and the moment you notice it. Our solution is almost embarrassingly literal: we send ourselves money, all day, every day, on every network we operate, and get paged when it doesn’t arrive on schedule. We call these payments canary transfers.

The late file

In the early days of Increase, an uncaught head-of-line blocking serialization bug caused us to submit a file of transfers to the Fed late, and we missed a same-day ACH settlement cutoff. The transfers landed hours behind schedule. For a customer running payroll, that’s serious: the money has to arrive on time or people can’t pay their mortgages. Worse, it took hours to notice. Had we caught the delay immediately, we could have re-sent the transfers over wires; by the time we saw the problem, that option was gone.

The postmortem fixed that bug, but the next incident will be something else. Whatever it is, we’d rather find out in five minutes than five hours.

Sending ourselves money all day

Engineers already have a tool for this shape of problem: synthetic monitoring. In a typical web stack, you run a script that continuously hits your endpoints so you find out something is broken before your users do. A canary transfer is the same idea, except the request is money and the endpoint is the Federal Reserve.

Our first version was under fifty lines of code: send an ACH transfer between two accounts we own, then poll the receiving account until the balance moves. We built it on top of the same public API our customers use, so anything customer-facing in the stack gets exercised on every loop.

ACH is ideal for canaries because its timing is predictable. A transfer we hand to the Fed at 10:00 AM Eastern Time makes the 10:30 AM same-day window and settles at 1:00 PM, so we place a canary in every outbound FedACH file and page if a canary transfer in that file hasn’t settled by 1:05 PM. We time the canaries so one settles during every ACH window. That signal turned out to be useful enough that we now publish it on our public status page.

We run a version of this on every rail. Wires settle almost instantly, so we send ourselves one every hour, and we do the same over Real-Time Payments and FedNow. Cards get the full loop: every minute, we issue a new card on our infrastructure and authorize a live transaction. And to cover the physical world, we mail ourselves at least one paper check every day, which tests printing, the mail, and lockbox deposit end to end. Somewhere in a USPS truck right now is an envelope we addressed to ourselves, running an integration test at the speed of mail.

What a canary can and can’t tell you

A canary tells you the air is bad, not which gas is leaking or where it’s leaking from. If a file gets stuck, the round trip fails and we get paged, but the canary won’t say whether the cause was a bad deploy, a Fed issue, or something we haven’t imagined yet. To find the root cause, we rely on a separate invariant-monitoring framework called Checker, which continuously asserts specific conditions about the state of our systems. A canary tells us a file is stuck; a failing check tells us which step it’s stuck on.

Sometimes the answer is that nothing is wrong on our end at all. We occasionally get paged because a payment network itself is running slow. That’s fine! Those pages still shrink the time between something changing and someone starting to look.

And those false alarms carry real information. Because we authorize a card transaction every minute, we know within a minute if there are any issues with the Visa network. Because we mail ourselves a check every day, we know when the USPS is having a slow week. So when a customer asks why the check they mailed a week ago still hasn’t been deposited, we can answer from our own data: the mail really is slow, and we know because we’re feeling the same conditions our customers feel.

Boring is reliable

If you build infrastructure that touches the physical world, reality’s surprising details will eventually break your models. Unlike monitoring that watches from the outside, canaries participate: our money rides the same rails, meets the same cutoffs, and sits in the same mail trucks as our customers’ money.

Sending yourself money all day will never be glamorous. It’s still the most dependable way we’ve found to keep learning the details the manual leaves out.

Vantaca partners with Increase to launch Vendor Pay

Fri, 26 Jun 2026 00:00:00 GMT

Vantaca, a leading platform for community association management, launched Vantaca Vendor to let property managers pay vendors directly from the same system where they manage invoices, approvals, and accounting. The solution is powered by Increase, a modern banking core that helped Vantaca replace a fragmented stack of payments tools with a single integration — launching and scaling in weeks, not months.

Seeing like a network: the merchant category code

Mattt Zmuda — Mon, 08 Jun 2026 00:00:00 GMT

Suppose you’re building the financial infrastructure for a logistics network. You need to issue physical corporate cards to truck drivers so they can pay for fuel and maintenance. Or maybe you’re engineering the payment flows for a delivery platform, issuing zero-balance cards to couriers to buy groceries for customers at the point of sale.

In both cases, you need to guarantee that each card buys what it was issued for, and nothing else.

At Increase, you enforce this programmatically via a synchronous webhook on Real-Time Decisions.

When a courier swipes, dips, or taps their card, the payment terminal generates an ISO 8583 0100 Authorization Request. This message traverses the card network on its way to us. We intercept it mid-flight and, while the terminal and network wait for an answer, send a real-time webhook to your server.

That thin webhook tells you an event happened and hands you an ID:

{
  "type": "event",
  "category": "real_time_decision.card_authorization_requested",
  "associated_object_type": "real_time_decision",
  "associated_object_id": "real_time_decision_123abc"
}

You fetch the decision itself with a GET to /real_time_decisions/{id}, which returns the authorization details:

{
  "id": "real_time_decision_123abc",
  "category": "card_authorization_requested",
  "status": "pending",
  "card_authorization": {
    "decision": null,
    "presentment_amount": 14550,
    "presentment_currency": "USD",
    "merchant_category_code": "5411",
    "merchant_acceptor_id": "1234567890",
    "merchant_descriptor": "SAFEWAY STORE 0021"
  }
}

You have about four seconds to ingest this payload, evaluate it against your internal state machine, and POST your verdict back to /real_time_decisions/{id}/action:

{
  "card_authorization": {
    "decision": "approve"
  }
}

Once your action POST completes, you return a 200 OK to the original webhook, and the transaction resumes.

One of the highest-signal fields for evaluating the authorization request is merchant_category_code.

You don’t have to make every call live, either. Increase’s API lets you pre-configure static authorization controls on a card, allow-listing or blocking specific merchant category codes outright, so you can reserve Real-Time Decisions for the cases that genuinely need a judgment call.

Seeing like a network

In his book Seeing Like a State, James C. Scott explores the concept of “legibility.” A state (or any complex organization) can’t govern without first simplifying reality. To manage a dense, old-growth forest, for example, the state clears it and plants identical trees in straight rows. To calculate taxes, a 19th-century tariff regime declares that a tomato is a “vegetable,” not a fruit.

The global payment networks operate the same way. Governed by the International Organization for Standardization under ISO 18245, the Merchant Category Code (MCC) is Visa and Mastercard’s instrument of legibility.

Modeling a messy, contradictory world is an impossible task; no taxonomy ever fits perfectly, and some are simply better than others. The MCC is serviceable, but its quirks run deep.

Originally designed in the 1970s to calculate tiered interchange fees (a jewelry store presents a higher fraud risk than a bakery, and is priced accordingly), the MCC maps global commerce onto a rigid numeric grid, keyed to a business’s primary consumer-facing activity. But how do you classify a 200,000-square-foot mega-mart that sells tires, prescriptions, milk, and life insurance? You oversimplify. To the network, a merchant is whatever it sells most of. The grid compresses reality into a four-digit integer, producing outcomes by turns comical and genuinely inconvenient.

Hardcoded history

The full ISO 18245 taxonomy reads like a fossil record of 20th-century commerce. The system encodes point-in-time business realities as permanent infrastructure.

Specific entities from the 1970s and 80s are hardcoded into the global grid. Major carriers get their own: United is 3000, American is 3001, each reserved exclusively for that airline. The networks maintain 3667 purely to identify transactions at a single casino hotel: the Luxor in Las Vegas.

The grid is just as lopsided in the other direction. For every entity rich enough to earn its own code, whole swaths of commerce funnel through a single overloaded one. A corner café, a food truck, and a hotel banquet hall can all land under the same restaurant code, while a genuinely new kind of business picks among a half-dozen overlapping food-service options, none a clean fit. And the granularity is wildly uneven. The same grid that crams all of food service into a handful of codes keeps dedicated entries for furriers (5681), wig shops (5698), and snowmobile dealers (5598).

When the abstraction leaks

The grid’s real trouble is that it can’t keep up. When new business models emerge, it buckles.

Authorizing a fleet card seems trivial: you allow-list MCC 5542 (Automated Fuel Dispensers). But when electric vehicle charging networks scaled, they lacked a dedicated identifier. Some acquirers miscategorized EV chargers as generic utilities (4900). If your fleet transitioned to EVs, your programmatic webhooks started declining legitimate charges or approving ambiguous ones.

A specific code for EV charging (5552) was eventually introduced, but implementation remains fragmented. Updating an MCC isn’t a cloud deployment; it often requires the acquiring bank to reclassify the merchant in its core systems and manually push a configuration change to a physical point-of-sale terminal in a parking lot. For an independent station owner, there’s zero financial incentive to initiate this process just so a driver’s corporate card categorizes the spend correctly.

This kind of mismatch reveals a deeper limitation. MCCs classify the entity, not the basket. By default, the ISO 8583 payload can’t distinguish between a cart of groceries and a flat-screen television rung up at the same big-box store. The code tells you where the card was swiped, but nothing about what was actually bought.

Some transactions do carry richer, itemized data alongside the authorization, but it’s supplemental, inconsistently supported, and a subject of its own; the base authorization still identifies the merchant, not the purchase. When you’re writing authorization logic against the category code, you’re making decisions based on who the merchant says they are, not what the cardholder is doing.

From entity to intent: ISO 20022

The MCC has been a durable piece of financial infrastructure for fifty years. But as global commerce shifts, its dominance is waning.

The structural threat isn’t a new set of codes; it’s the bypass of the card networks entirely. As Open Banking and direct account-to-account (A2A) payments scale via rails like the UK’s Faster Payments, Europe’s SEPA Instant, or the FedNow network, transactions no longer traverse Visa or Mastercard. They don’t use ISO 8583 or carry an MCC.

To prevent a data void in spend categorization, the global financial system is migrating to the ISO 20022 messaging standard. This replaces legacy flat files with highly structured, extensible (if charmless) XML.

Imagine you’re building the financial flows for that same logistics network, but ten years from now. Instead of a driver swiping a physical corporate card at a gas station, the connected fleet vehicle initiates a real-time A2A transfer over FedNow to settle the charging fee directly with the EV station.

When your webhook fires, you aren’t checking a merchant’s category code. ISO 20022 carries a dedicated Purpose Code that defines the intent of the transfer. Inside a standard pacs.008 customer credit transfer payload, you parse the <Purp> element:

<Purp>
  <Cd>ENRG</Cd>
</Purp>

Values like ENRG for energy, AIRB for air transport, or SALA for salary define intent natively in the payload. The classification moves from the entity (who the merchant is) to the intent (why the money is moving).

Note AIRB (and resist the autocomplete to AirBnB): it names the purpose of the payment, not the merchant behind it. Where the card networks split air travel across dedicated carrier codes like United’s 3000 and a generic catch-all (4511), ISO 20022 simply carries a field that means “air travel.”

Migrations of core financial infrastructure are slow. The transition to ISO 20022 has been repeatedly delayed by central banks, and the volume of physical point-of-sale hardware ensures legacy mainframes will remain operational for decades. Swift held its November 2025 deadline to retire cross-border MT payment messages, but a long tail of message types and address formats runs into 2027. The transition will be measured in business cycles, not quarters.

Until that migration is complete, if you’re building programmatic spend controls, you’re living in the world of the MCC. That’s a more workable place than it sounds. The taxonomy is messy, but it’s also shared and public, so you can design for its edges deliberately instead of discovering them in production. Treat the category code as a strong hint rather than a verdict: keep your allow-lists in configuration, not code, so they change in minutes rather than a deploy; log the code and your decision on every authorization, so a miscategorized EV charger surfaces as a pattern instead of a support ticket; and fold in new codes like 5552 as they come into use.

The highest-leverage move is making the taxonomy more legible to each other. The 50-year-old grid isn’t going anywhere soon, but the tooling we wrap around it can be modern, shared, and a good deal more legible than the grid itself.

Why we’re still talking about paper checks in 2026

Sacha Perold — Thu, 30 Apr 2026 00:00:00 GMT

We’re not going to sell you on the benefits of sending checks. If you’re sending checks in 2026, you’re doing it because you have to.

Many healthcare, real estate, and insurance businesses still rely on checks to send and receive funds. While the majority of our transactions are digital, Increase processed billions of dollars in old-fashioned paper checks in the past six months.

So we invested heavily in features that support platforms scaling check send: support for attachments, overnight shipping, delivery notifications, design customization, and fraud controls.

If you don’t send checks at scale, congratulations! You can read the unmitigated pedantry that follows just for fun.

Checks love company

If you’re going to the trouble of putting a check into an envelope, you may want other things in there too.

Attachments to checks can be useful for a range of use cases. Bill Pay platforms include remittance information for invoices. Healthcare platforms send explanations of benefits. Some companies send marketing materials along with each check to acquire counterparties as customers.

Speed matters, even when you’re sending paper checks

When we initially built our check send API, we assumed our users would always prefer the cheapest mailing option and wouldn’t be particularly sensitive to shipment times.

This turned out to be wrong! The CheckTransfer API now supports Fedex Overnight shipping.

Users often send checks when collecting bank details isn’t possible or desirable. This includes refunds, rebates, settlements, class-action payouts and more. And sometimes those payments are urgent.

It’s nice to know where your paper check is

Our users want to give their customers delivery update notifications. So we found ourselves integrating into the United States Postal Service and the FedEx APIs to get these for them. For USPS, that’s the Informed Visibility® Mail Tracking & Reporting (IV-MTR).

You may have had the experience of receiving an in-transit notification a few days after the package is delivered. Delivery tracking update events use operations codes, and there are a little less than 1000 different codes. (Fedex, mercifully, uses only a few dozen).

The result is a straightforward and readable timeline, so you can track every step of your paper check’s journey to its destination. We now surface these tracking updates in the Dashboard.

Customization requires going direct-to-printer

To deliver much of the above, we invested in integrating into an industrial printer. Their preferred delivery format from us was a single, very large PDF, with all of a day’s checks and attachments in a single file. (As you might expect, this created a side quest around file size optimization).

This unlocked an ability to customize appearance on a per-check basis. The American National Standards Institute’s standard for checks specifies the font (E-13B), the placement of the magnetic ink character recognition line, and the paper used. But that leaves a fairly wide space for customization, which we’re excited to support.

Fraud controls are critical

No matter how beautifully customized your paper checks may be, they quickly become a hassle if lost or stolen. This unfortunately does happen, and when it does, you’ll need controls to block checks from being fraudulently deposited.

We now offer fine-grained positive pay controls on every Check Transfer, allowing users to review attempted deposits before funds get withdrawn from an Increase account, and decline the deposit attempt for any reason.

Designing for programmable paper checks

At Increase, we default to building financial primitives with no abstractions for flexibility, transparency and reliability.

For this reason, we resisted investing in a printer integration. Our customers are large, sophisticated financial technology companies: maybe they’d prefer to bring their own printer integration for checks?

They didn’t.

So, where it made sense, we picked up as much of the toil as we could for printing and mail tracking. And by directly integrating into an industrial printer for printing, USPS/FedEx for tracking updates, and Check21 for money movement, we’re able to offer API-powered paper checks that are programmable and flexible.

If you’re sending checks at scale, let’s chat! Reach us at hello@increase.com.

2026 Q1 Newsletter

Sat, 25 Apr 2026 00:00:00 GMT

Here’s what we shipped in the first quarter of 2026.

Accounts and Entities

We launched our Entity Onboarding Sessions API, which lets you use our hosted authentication UI to collect your customers’ information during onboarding without having to build the KYC flow yourself.
Eligible platforms can now set the interest rate for each of their Accounts.
You can now create a voided check via the API, which is useful for sharing your account and routing numbers with a counterparty in a familiar format.

Money movement

Card authorization controls now support per-card spending limits, with single-use and multi-use cards; per-transaction, per-week, per-month, and per-year limits, giving you fine-grained control over where and how each card can be used.
We launched 3D Secure for card authentications, letting you authenticate your cardholders at checkout to reduce fraud and disputes.
We launched Push Provisioning, letting your users add their card to Apple Pay and Google Pay directly from your website or native app without typing in a card number.
We’re now fully reconciling and passing on all scheme fees from Visa, so the card-network fees on every card payment match the network’s books exactly.
We now support attaching up to 999 pages to a single check, for use cases like remittance and lockbox payments where you need to mail substantial documentation alongside the check.

Developer experience

You can now restrict API keys to a list of IP addresses, reducing the scope of impact if a key is ever compromised.
You can see what an object looks like in the API directly from most Dashboard detail pages via the “Show API representation & events” link, which is handy when debugging an integration without dropping into a terminal.
The Event polling API is now generally available - you can poll for new Events instead of listening via webhook, which substantially reduces end-to-end Event handling latency.
You can now manually trigger a webhook delivery for an Event from the Dashboard, which makes it easier to debug webhook handlers or replay after an outage on your side.
You can now subscribe an Event Subscription to multiple Event categories at creation time, instead of registering a separate subscription per category.
Increase SDKs are now available in C#.

Things we wrote and said

We were named to the Forbes Fintech 50 list for 2026.
Our founder Darragh joined the Fintech One-on-One Podcast to talk about bank infrastructure.
We wrote about what it’s like to work with Increase, and why our engineers handle their own support rather than running a dedicated support team.

Support that doesn’t scale: what it’s like to work with Increase

Jamshed Vesuna — Wed, 22 Apr 2026 00:00:00 GMT

At Increase, we open a shared Slack Connect channel for each new customer (and prospective customer). Our engineering team is a part of the channel and whoever is on-call responds to customer questions directly. We don’t have a traditional support team; the same engineers who build the system also operate and support it.

A customer recently asked us about adding support for voided checks to our API to help demonstrate account ownership. At most companies, that request would have gone to someone in Support or Customer Success, then added to a queue of potential feature requests. In this case, the engineer who owns our Check Transfers product was able to gather additional context in real-time, iterate on the request with the customer, and push the new API to production the following day.

“With Increase, we have high confidence that systems are running smoothly. And if something goes wrong, we can quickly drill down into the issue and act before it affects payroll. This level of control has been critical for us.” - Andrew Brown, CEO at Check

This is a natural extension of our model of empowered owners, where the person responsible for a given feature (usually an engineer) is responsible for the full stack of ownership and decision-making, from the underlying network integration to the product design to the sales and support of that feature. We believe in giving our employees the context and the agency to fix, tinker, and build.

When you send us a note in our joint Slack channel about something that’s broken, needs improvement, or needs to be built, you’ll talk directly to an Increase engineer. We think this matters for a few reasons:

Lack of translation

When customer feedback travels through layers of support, account executives, product managers, and engineers, each step adds latency and subtracts fidelity. Talking directly to the owner gets our customers faster, better answers, and lets us move more efficiently as an organization. When a traditional support team is receiving questions and bug reports, they’re often incentivized to find workarounds for defects and bugs in the name of closing tickets. When the engineering owner is receiving them, they’re incentivized to fix the bugs and improve our documentation.

Tight feedback loops

Our product spans complex systems and serves demanding customers. Feedback is oxygen to us. If we ship a feature that generates pain or confusion for our customers, the person responsible for it will feel that pain viscerally and immediately. This acts as a self-regulating mechanism - engineers can’t afford the support burden that shipping subpar work will cause them.

Nuanced conversations

In many cases, the questions we receive involve a lengthy back-and-forth. The US depository system is powerful and complex. If you’re not talking to someone with a deep understanding of the systems at play, you may not get the answers or resolutions you need. It helps to talk to experts who operate in complex systems because they can connect the ways your use case fits into those systems.

“I appreciate your decision to have an engineer serve as the equivalent of an account manager. I know it’s not an easy decision, but it makes a big difference for us. There’s no customer <> AM <> engineer loop, and it feels like the answers come straight from the source of truth.” - Perry Zheng, founder and CEO, Cash Flow Portal

Ultimately businesses come to Increase for access to speed, transparency, and reliability. We feel that should be as true when working with our team as it is when working with our machines.

Increase named to the 2026 Forbes Fintech 50

Thu, 19 Feb 2026 00:00:00 GMT

We’re honored that Forbes named Increase to its annual Fintech 50 list for the second year in a row. And we’re in great company, alongside customers like Stripe and Ramp.

Some reflections on recent milestones that got us here:

Increase now processes hundreds of billions in payments volume per year. We handle a growing number of API calls while maintaining latency of under 100 milliseconds.
We added powerful new rails for instant money movement: FedNow and Push-to-card transfers. Alongside Real-Time Payments, Increase now supports every US instant payment network.
We shipped improvements to our existing rails: Check Transfers now offer attachments, overnight shipping, delivery notifications, design customization, and fraud controls. Our Lockbox offering enables users to spin up unique locations to minimize latency. And we saw growing adoption of Wire Drawdowns for use cases like payroll and bill payment.

We’re most grateful for the ambitious companies building the next generation of banking, payments and card products on Increase. In their own words:

With Increase, we have high confidence that systems run smoothly. And if something goes wrong, we can quickly drill down and act before it affects payroll. This level of control has been critical for us.

— Andrew Brown, CEO of Check

Increase has been a critical partner in helping us launch products that feel as modern and intuitive as the rest of Ramp’s offerings. The flexibility and transparency is unmatched.

— Nik Koblov, Head of Engineering at Ramp

Thank you, Forbes, for the recognition. And now, back to work!

— The Increase team

2025 Q4 Newsletter

Wed, 31 Dec 2025 00:00:00 GMT

December 31, 2025

FedNow is live. FedNow is an instant payment network that’s ergonomically similar to Real-Time Payments (RTP) but administered directly by the Federal Reserve.
We launched support for Push-to-Card transfers on Visa and Mastercard. You can now instantly send funds from an Increase account to the majority of US debit cards.
Our new Cards Disputes API is live. It’s directly integrated to Visa Resolve Online (VROL) APIs and lets you pass structured data for every type of dispute Visa supports, optimizing your UX and win rates.
We launched Push Provisioning: your users can add their card to their Apple Pay wallet from your app without having to type (or know) their card number.
We added support for attachments, overnight shipping, and design customization to Check Transfers.
Increase SDKs are now available in PHP and Ruby.
You can see what an object looks like in the API directly from the Dashboard.
You can see Increase’s live system metrics directly on our Status Page.
All our documentation is now LLM-friendly: copy or send any docs page to an LLM, and when robots browse our site they get markdown.
We wrote about why platforms have unique data insights to deliver small business lending to their customers.
We published a guide to embedding banking and payments into Vertical SaaS companies.
Our founder Darragh talked about bank infrastructure on the Fintech One-on-One Podcast.

Lending, fast and slow

Sam Ballantyne — Tue, 14 Oct 2025 00:00:00 GMT

Small‑business lending bifurcated over the last decade.

If you run your business on a platform like Stripe or Square, and need a working capital line, you can get it fast. The big payment processors have eaten up a huge chunk of the market for short-duration, low-dollar lines. Merchants get a decision in seconds and funding next day.

But if you need a larger or longer duration loan, you’re stuck in a much slower world. You’re downloading your account statement then uploading it back again to the loan portal at the same bank. You’re reading through pages of covenants. You may wait months.

How did fintechs win so much of the market for small business working capital — and why did it stop there?

We’ve argued elsewhere that vertical software is the new distribution model for financial services. This post covers why we think that’s true with lending, especially.

Extending credit with the data on-hand is fast

Stripe, Shopify, and Square all play in this market. The offer shows up where you sell. You drag a slider to pick an amount, accept the fee, and money appears. Terms are short — 9 months on average — and amounts comparatively small, mostly well under $100k. Repayment happens automatically, ebbing and flowing with your sales.

It’s worth calling out what a great user experience this is. I’ve talked to founders who say they never would have applied for a loan, but seeing it teed up in front of them changed their mind.

The great part is the speed. You know you qualify before you apply. The trick is prequalifying merchants based on sales data — processing volume, payment history, customer mix, seasonality — and not considering anything they wouldn’t be able to know ahead of time.

The downside of this tight credit box is eye-popping charge-off rates: 5, 10 or even 15%. Payment processors stay ahead of these with high interest rates and fees.

Large loans require data that banks don’t have on-hand

Meanwhile, if you need capital to buy equipment, or real estate, or otherwise expand, you’re dealing with a bank, and it is not fast.

You are not pre-qualified. You begin a weeks-long process, uploading every excruciating detail of yours and your company’s financial life, without any promise of success.

Why is it this way? Because underwriting these deals is hard. Every banker knows they can give back ten years of gains in one bad quarter.

Heterogeneity doesn’t help. One week underwriters review a new site for a craft brewery, the next week a renovation at an auto body shop. Different industries have different labor markets, regulatory risks, and collateral valuations. Generally, underwriters aren’t actually adjusting the ratios they’re looking for by industry: instead they adjust their thresholds portfolio-wide to be on the conservative side.

And underwriters look at everything. Tax returns, financial statements, collateral, insurance, appraisals, and comparables. This rigor mostly pays off! Charge-off rates on business loans from banks hover around 0.5%.

This is not a great product experience. But it doesn’t have to be. Business owners looking for expansion capital don’t have a better option.

A better option

Let’s say you have a property that you rent out on Airbnb. It’s going well, and you’d like to expand by adding a second unit.

You can see why Airbnb’s payments processor isn’t in a good position to give you this loan. They can see your payment history, but not much beyond that.

The local community bank may do better! However, the underwriter would have to make guesses about unfamiliar areas. And you’d have to commit to the application process itself.

The best-positioned party to underwrite this loan is Airbnb itself. They see your reviews, cancellations, calendar; your property’s location, amenities, and comparables; how often travelers search for terms it matches; how long travelers linger over photos of the picture windows.

This is why we think industry-specific platforms, whether they’re marketplaces or vertical SaaS, are so well set up to make embedded finance plays. They have the data and distribution. They understand their customers’ businesses. While these loans can and will remain mostly sold, they can do most of the data collection at the pre-qualification phase. The challenge for them is finding a partner with right technology, capital, and underwriting capacity.

At the end of the day, the lender that can squeeze the most risk out of the portfolio and win on user experience is going to run away with the show. If you’re building in this space, we’d love to chat! Reach out at sam@increase.com.

Agentic commerce — the Increase perspective

Sam Ballantyne — Thu, 18 Sep 2025 00:00:00 GMT

Agents based on large language models are doing more and more for us. Empowering them to make payments is a live frontier.

Agentic commerce is often cited as the breakthrough use case for stablecoin payments. See Why Agentic Commerce Needs Crypto to Scale from Coinbase. Stripe’s new Tempo blockchain is built with a similar motivation.

At Increase, we have a boring perspective: the existing rails are best.

A consumer use case

I recently took a summer vacation to the Alps. ChatGPT did much of the heavy lifting in finding hikes, hotels, restaurants, and train tickets. With due affection for the rigor and thoroughness that Europeans bring to building web forms, I would have loved to have ChatGPT book everything for me. It can’t today, but soon it will. And when it does, I will want it to use my existing credit cards.

Partly this is for the rewards and benefits; the partner-specific benefits were one criterion I asked ChatGPT to consider in its research.

But beyond the rewards, the biggest reason is the protection of Visa’s dispute machinery. As agents become targets for scammers, I want the full dispute apparatus of the card networks behind me.

I expect product innovation from card issuers and acquirers here. If I were building this, I might spin up per-purchase virtual cards with a nice user-facing approval flow. Just as cards fight to be top of wallet, they’ll fight to be the card you give to ChatGPT.

A commercial use case

Businesses of all sizes receive a large volume of invoices. Validating these is toilsome: Did we really authorize this? Is this invoice early? Is this the negotiated amount? Is someone impersonating our vendor?

This kind of checklist is reasonable for an agent to track down; but when it comes time to move money, they’ll likely use the same payment rails the operator would in the first place. Most of the time, that’s cards or bank transfers. That’s where payee preferences lie, and it’s where dispute protection lives.

By the way, this is a real use case today. Ramp is doing some amazing work around agent-powered bill pay. If this is a problem you have, we highly recommend signing up: https://ramp.com/bill-pay.

A speculative use case

Cloudflare recently announced a pay-per-crawl blocker:

Imagine asking your favorite deep research program to help you synthesize the latest cancer research or a legal brief… and then giving that agent a budget to spend to acquire the best and most relevant content.

It’s early days, but intuitively this use case feels real. Today, valuable data is monetized in an all-or-none fashion designed for human readers: newspaper subscriptions, Bloomberg terminals, trade journals.

A potential challenge for existing rails here is cost. One could argue that stablecoins are a better fit for the market-clearing price of many of these transactions. But as with any low-dollar usage-based product, I suspect that these kinds of payments are likely to be settled in batches as part of broad commercial relationships.

Wrapping up

Hypotheses should be falsifiable, so here’s ours: payments initiated by agents are going to skyrocket over the next two years, but the funding mix won’t look much different than it does today.

That agentic commerce doesn’t require reinventing money movement is a reason we expect it to take off. The existing rails work. What matters is giving agents programmable, low-level access to them and building the dispute protections and workflows that make them usable at scale.

Embedding financial services in vertical software

Matt Hennessy — Tue, 09 Sep 2025 00:00:00 GMT

Embedding financial services in industry-specialized software is good for customers, good for software companies, and good for banks. But to do it well, you need direct access to banking fundamentals and a willingness to understand how money actually moves.

Vertical software as the new distribution model

Traditionally, banks have specialized by geography. A community bank knows and understands its local customers deeply. But geography isn’t always the right proxy for customer needs. A dentist in Portland, OR has more in common with a dentist in Portland, ME than with a dry cleaner next door.

Industry specialization has always existed in banking. J.P. Morgan financed railroads. GMAC was created to finance the auto industry. What’s different now is that specialization increasingly comes from software, not banks. Vertical software platforms run tailored workflows for specific industries: dentists, insurance agents, contractors, nonprofits. And because those workflows often involve money, software platforms are naturally expanding into payments, bank accounts, lending, and more.

Think of a software platform for beauty businesses that not only manages appointment booking, but also handles embedded payroll and tailored loans for salons and spas. Or insurance software that started with accounting flows, and now handles client invoice payments and payouts to carriers.

Why payments literacy matters

Can a software company really be expected to understand banking? At Increase, we think yes.

Not everyone on your team needs to be a payments expert, but someone should be. Just as pizza software like Slice needs someone who understands oven throughput, vertical software teams embedding payments need someone who understands settlement timing, reconciliation, and network behavior. Your product will be stronger for it.

The good news: the lift to access and understand payment details isn’t as heavy as it once was. With Increase, those details are exposed directly to you, rather than being hidden behind layers of middleware. Our direct connections to the Federal Reserve, Visa, and The Clearing House make financial primitives programmatically accessible. You can test, monitor, and refine payments flows just like any other system that matters to your business.

Building on financial primitives

Embedded finance starts with financial primitives: accounts, payments, lending. They’re the building blocks. What matters is assembling them for the unique needs of your industry. For example:

A property management platform building on Increase can debit rent through same-day ACH in the morning, see funds settle midday, and pay contractors seconds later via Real-Time Payment.
A nonprofit software platform can assign every inbound donation its own Account Number, reconciling funds automatically down to the penny.
An agriculture software provider can programmatically send paper checks and expose each lifecycle event — printed, mailed, deposited — giving farmers the transparency they expect. With direct, low-level access, the financial system becomes flexible enough to map to the workflows you already run.

Better outcomes with no abstractions

Embedding financial services inside vertical software creates better outcomes across the board. Customers get integrated, reliable workflows. Software companies unlock new revenue streams and deeper retention. And banks gain distribution into industries that would otherwise remain fragmented or underserved.

If you’re a vertical software platform launching embedded payments or financial services, you might be tempted by abstractions that hide complexity. But we’ve seen again and again that real speed, flexibility, and reliability come from building on financial primitives with no abstractions.

That’s the work we’re doing at Increase: giving vertical software platforms the modern banking core they need to build financial services that are seamless, resilient, and built for the industries they serve.

If you’re building in this space, let’s talk! Reach us at hello@increase.com.

2025 Q2 Newsletter

Mon, 30 Jun 2025 00:00:00 GMT

May 30, 2025

You can now filter API event logs in the Dashboard by the request path.

May 9, 2025

We’ve made a number of improvements to the Event page in the Dashboard to give you more insight across your integration. You can now filter event logs by the associated object. We’ve also added an event timeline that gives you more context surrounding the event, as well as more details about the request and response lifecycle.
You can now reverse an Inbound Wire Transfer . This is useful if you received a duplicate wire or the recipient of the wire transfer requested the funds be returned to the sender.

April 18, 2025

You can now include an attachment when sending a Check Transfer .
You can now send a Check Transfer using FedEx Overnight by setting the shipping_method parameter.
You can now accept requests for late ACH returns in the Dashboard.

April 4, 2025

You can now add international beneficial owners to a corporate Entity.
We now surface the cardholder name and device information on Digital Wallet Tokens .
You can now view Digital Wallet Tokens in the Dashboard.

Check partners with Increase to enable payroll

Thu, 26 Jun 2025 00:00:00 GMT

Check is a leading embedded payroll infrastructure, giving businesses the ability to integrate payroll directly into their platforms. Whether those platforms are designed for coffee shops or construction companies, Check ensures their payroll operations run efficiently – supporting thousands of businesses and hundreds of thousands of employees. Their mission is to simplify payroll, making it seamless, scalable, and accessible to platforms of all shapes and sizes. However, achieving this goal requires more than functional software—it depends on having high visibility into the underlying financial networks and access to faster payment methods, areas where traditional banking partnerships can fall short.

2025 Q1 Newsletter

Mon, 31 Mar 2025 00:00:00 GMT

March 21, 2025

You can now generate an unauthenticated URL for a File using File Links . This is useful if you want to share a File with a customer, auditor, or other third party.

February 21, 2025

Deposit images from inbound checks are now viewable directly inline in the Dashboard.

January 31, 2025

Incoming check deposits are now visible in the Dashboard.
Apple Pay transaction history is now available for cards in your Apple Wallet.

January 10, 2025

Declined Transactions with a source of check_decline now display negative amounts to better reflect the intended direction of fund flows. Please note that these transactions are informational only and do not represent actual financial messages.
You can now quickly create a duplicate Transfer in the Dashboard. Simply navigate to the Transfer detail view and select “Draft Duplicate” to pre-fill the Transfer details for faster entry.

How Ascend facilitates payments and automates insurance AR/AP workflows with Increase

Mon, 31 Mar 2025 00:00:00 GMT

Ascend is a leading finance automation platform in the insurance industry, streamlining the entire payment lifecycle, from collection and accounting to reconciliation and disbursement. By automating these processes, Ascend helps insurance businesses simplify treasury management, eliminate repetitive, time-consuming operational tasks, and provide a better customer experience. The result is greater profitability for its customers which include leading agencies, MGAs, and insurance carriers.

Compliance as code

Jamshed Vesuna — Mon, 24 Feb 2025 00:00:00 GMT

As an engineer, how do you ensure that a code change doesn’t inadvertently break a compliance or legal obligation? More fundamentally, how do you even know what those obligations are?

Conway’s Law tells us that compliance and engineering teams tend to operate in separate systems that rarely talk to each other. As a result, policies, procedures, and legal frameworks live in one world, while production systems live in another. This disconnect creates risk—what’s written in a compliance document may not reflect what actually happens in production.

We think there’s a better way to approach this.

What if your application’s code also helped manage its regulatory, compliance, and legal requirements? You’d have a source of truth for all your obligations and encoded tests to ensure they are continuously fulfilled. This would eliminate discrepancies with outdated documents and prevent you from making a change if it would bring you out of compliance. Not only would this remove uncertainty when heading into an audit or exam, but it would essentially provide an internal automated audit function—ensuring compliance is proactive, not reactive.

This system is one of the many ways we’re scaling compliance at Increase.

How it works

Our system has three concepts: Obligation Documents, Obligations, and Fulfillments.

Obligation Documents define a whole regulatory or compliance framework, such as the System and Organization Controls (SOC) or Truth in Savings Act (Regulation DD). Obligation Documents live in code, not data, and define the source of truth for its obligations and audit lifecycle.

Obligations represent the individual, verifiable requirements for our business. Every Obligation is associated with a parent Obligation Document—which contains many individual Obligations.

Fulfillments are executable code that verify if an Obligation is met. There can be one or more Fulfillments associated with a single Obligation. Additionally, Fulfillments can take one of five implementation shapes.

Types of Fulfillment

Code Enforcement: These fulfillments can sit in the test suite. For example, checking that transactions are processed in a certain order.

State Checks: These fulfillments involve checking the state of databases or external systems. For example, ensuring that all entities have verified tax IDs, financial ratios fall within acceptable ranges, or that external systems (such as firewall deny lists) are properly configured, monitored, and alerted.

Policy Enforcement: These fulfillments require written policies or procedures. For example, ensuring there is a policy in place to assess third-party contractors and vendors for risk to Increase.

Manual Assurance: These fulfillments verify that a named role within the company makes a regular assurance about the current state. For example, that security incidents have been examined by the Chief Information Security Officer.

No Action: Some obligations cannot be actioned by us because they require regulatory intervention. For example, conducting specific interviews. These obligations are tracked for completeness.

Testing

All of our Obligation Fulfillments run on our Checker framework, which manages the execution scheduling and handles the results in an easy to use interface.

The neat thing about bringing obligations into your codebase is that the source of truth for requirements lives as close to the implementation as possible.

Let’s look at an Obligation based on a 2010 Federal Deposit Insurance Corporation (FDIC) order to address compliance issues with overdraft fees and transaction processing:

code_enforced_obligation(
  <<~DESCRIPTION,
    Transactions should be processed in a neutral order that avoids manipulating or structuring the processing order to maximize customer overdraft and related fees.
  DESCRIPTION
  'processes ACH credits before debits'
end

This is a deterministically provable statement that we can test against. In order to ensure we continuously remain in compliance, we have fulfillment code that looks like:

it 'processes ACH credits before debits', :regulations do
  account = make_account(balance: 10)
  debit_entry = make_entry(account, amount: -15)
  credit_entry = make_entry(account, amount: 20)
  FedACHEntryAllocating.run!
  expect(historical_balance_below_zero?(account)).to be_falsey
end

We therefore have a test in our codebase against our transaction processing system that enforces a certain processing order and links back to this Obligation.

Bidirectional linking

Often, the sub-organization building products is segmented from those interfacing with regulators and auditors. This can lead to many issues. In particular, audit requests ultimately branch out far beyond those interfacing with the auditor, either because it’s unclear how an obligation is fulfilled, it’s inaccessible to the working group, or the state of the system (a procedure, network diagram, access list, etc.) has shifted since the last audit.

A tremendous benefit of bringing regulations into code is the ability to link the source of truth (the implementation in code or policy document, for example) back to the Obligation which it fulfills.

This uniquely ensures that someone altering the implementation is aware of its otherwise opaque downstream impact. For example, a unit test may break that points back to the neutral transaction processing order Obligation, which gives a developer more context on why that code exists. Someone editing a policy document will see a footnote that links back to the Obligation, so they can proceed with cautious confidence.

The bidirectional link is also enforced by the system. A breakage in either direction notifies the team.

Why compliance as code works for us

For many businesses, this approach may feel too heavy-handed. Compliance automation platforms like Vanta provide powerful, accessible solutions that help companies quickly achieve and maintain compliance with standard frameworks. However, these platforms are optimized for common compliance requirements.

As banking infrastructure providers we, of course, adhere to common standards such as the System and Organization Controls (SOC) and Payment Card Industry Data Security Standards (PCI DSS). However, we also have bank-specific obligations, such as Regulation E (Electronic Fund Transfers), Federal Financial Institutions Examination Council (FFIEC), and Bank Secrecy Act (BSA) and additionally must comply with evolving regulatory guidance that introduces one-off obligations. These industry-specific requirements make off-the-shelf compliance solutions impractical for us.

Compliance as code offers a more flexible and precise way to manage our obligations. It enables our engineering and compliance teams to work from the same source of truth, fostering collaboration and mutual understanding. Engineers engage directly with regulatory guidelines, while compliance specialists can inspect and interact with the code that enforces them.

By embedding compliance into our development process, we ensure that regulatory requirements are continuously enforced, easily auditable, and integrated directly into our workflows — rather than maintained as a separate, manual function. This approach keeps our infrastructure both resilient and adaptable as regulations evolve.

Ramp launches Ramp Treasury, powered by Increase

Thu, 23 Jan 2025 00:00:00 GMT

Ramp is a financial operations platform that helps companies achieve more by spending less. From spend and expense management to bill payments and vendor management, Ramp’s all-in-one solution is designed to automate finance operations and help businesses grow efficiently. With the launch of the Ramp Treasury, Ramp has further expanded its suite of financial tools, offering an all-in-one cash and treasury portfolio that puts customers’ operating cash to work.

2024 Q4 Newsletter

Tue, 31 Dec 2024 00:00:00 GMT

December 27, 2024

You can now list your OAuth applications via the API.
You can now view the Groups connected to your OAuth Application in the Dashboard.

December 20, 2024

You can now view and create lockboxes directly from the Dashboard. Lockboxes provide virtual addresses for receiving checks, which are automatically deposited into their designated accounts upon arrival.
You can now export filtered data from tables in the Dashboard. Additionally, when reviewing your list of exports , you can easily return to the original filtered data.
Inbound check deposits can now be declined through the Dashboard within one hour of their deposit.

December 16, 2024

You can now filter objects in the dashboard by created_at date.
Cashback earned on individual card transactions is now visible in both the Dashboard and the API .
When exporting data from the Dashboard, you can more easily monitor the export status and retroactively view the specific data that was exported.

December 6, 2024

Payee information is now extracted from deposited check images for your initiated Check Transfers using Optical Character Recognition (OCR). This data helps mitigate fraud and supports informed accept or decline decisions. Contact support if you’d like to try this feature.

December 2, 2024

You can now quickly generate test data in Sandbox directly from the Dashboard. If no transactions have been created in your Sandbox environment, you’ll see an alert that lets you populate it with sample data, including a variety of transfers, account numbers, and a card with a settled authorization.
The stand-in processing reason for card declines is now available under network_details.visa.stand_in_processing_reason .
You will now receive emails for all transfers requiring approval. By default, all Owners, Administrators, and Finance Managers will be notified. However, you can update these email preferences at any time in Settings .

November 15, 2024

Sandbox simulations for creating an Inbound ACH Transfer, depositing a mailed Check Transfer, creating a Card Authorization, and settling a Card Authorization can be used from the Dashboard.
Sandbox simulations now support Idempotency Keys (except Card Authorization simulations).

ISO 8583: The language of credit cards

Martin Ek — Mon, 16 Dec 2024 00:00:00 GMT

ISO 8583 is the standard for real-time messages communicated between acquirers and issuers through all of the major card networks. Whenever you tap your card at a point of sale device or click “purchase” online, odds are it will eventually end up as an ISO 8583 message sent between the merchant’s acquiring processor, the card network, and your bank’s issuer processor. Early on, the point of sale device or the ATM might have built and sent the ISO 8583 message directly to the acquirer, but in today’s ecommerce environment messages typically pass from the merchant to a payment processor in higher-level formats, such as JSON, which then in turn are translated to the card network’s ISO 8583-based format. This approach simplifies the process by abstracting away the complexity of the ISO 8583 format from the rest of the payments ecosystem.

When the standard was first defined in 1987, it included the overall structure of the message specification and the names and lengths of the core fields, such as the card number (“primary account number”) in field 2 and the transaction amount in field 4. The message began with a 4-digit Message Type Indicator code representing whether it was an authorization message, a reversal, or some other message type. This was followed by a bitmap that told the recipient which fields were present. It left room for a few fields that could be used by networks to include network-specific information, and as a result the various card network specifications quickly diverged through a series of nested fields that did not overlap at all. Later versions of the standard greatly increased the number of fields, reducing the need for network-specific behavior for new implementations. Specifications like Visa’s Base I have thousands of clients running on everything from mainframes to devices like ATMs, however, making sweeping backwards incompatible changes next to impossible. As a result, these specifications still largely follow the rules set forth by the original standard from 1987.

The standard also allowed flexibility in how each field was serialized. For instance, networks could choose to use EBCDIC—the 8-bit encoding scheme favored by mainframes—for all fields, or opt for packed BCD to save space in numeric fields wherever possible. This made the specifications defined by each network, such as Visa, Mastercard, and Discover, eventually evolve to have more differences than similarities.

Throughout this article we’ll explore the basic structure of the ISO 8583 format before delving into its more complex nested sub-fields. In the end we’ll look at how you might define an ISO 8583 parser in code, grounded in how we process card transactions as an issuer processor connected directly to networks like VisaNet here at Increase.

Basic format

ISO 8583 messages can only be transmitted and received by parties with a shared specification detailing exactly which fields are present and in what positions. ISO 8583 messages, similar to other storage-efficient formats and unlike a more verbose format like JSON, carry only values and no field names. A basic message contains a “message type indicator” describing what type of message is sent, a bitmap explaining which fields are present, and the fields themselves.

Message Type Indicator

The message type indicator is a four-digit code that informs the receiver of the type of message being sent, such as an authorization message or a reversal. This tells the recipient which fields to expect to be present and not present in the message. While the specification defines a standard set of values—e.g., 0100 for an authorization request and 0110 for an authorization response—some networks deviate from these values and retain only the general concept. The way the indicator is serialized also varies between networks. Some networks use packed BCD to reduce its size to 2 bytes, while others use simpler formats like an ASCII or EBCDIC 4-byte value.

Bitmap

Most of the fields in an ISO 8583 message are optional, requiring the sender to convey which fields are present and which are missing. This is done with a bitmap, where each bit is set to 1 if the field is present and 0 if it is not. For example, 0110 1100 in the first byte of the bitmap communicate that fields 2, 3, 5, and 6 are present. The first bit in the first byte is reserved for communicating whether a second 8-byte bitmap is included, required when more than 64 fields are present. Similar to the Message Type Indicator, how the bitmap itself is serialized varies from network to network: hex, binary, ASCII, or EBCDIC are all possible choices.

Data elements

Following the bitmap, the sender serializes each present field in sequential order. Fields can be either primitive, containing a single value such as a string or an integer, or complex, containing nested fields within them. The serialization of primitive fields typically involves a combination of the factors enumerated below.

Encoding

Even for networks that prefer ASCII for their free-text fields, a serialized ISO 8583 message is usually not fully readable in plaintext, as the encoding of each field varies based on the type of field. There are generally a few options:

EBCDIC or ASCII: Typically used for freeform text but sometimes preferred for all fields, regardless of content. Some networks support both EBCDIC and ASCII and translate between the formats according to their participants’ preferences. The major networks usually default to EBCDIC, as this was the encoding of choice for IBM mainframes when the networks were first built.
Packed BCD: Often used for integers, with each digit occupying 4 bits. This encoding aligns with the 0-9 subset of hexadecimal, making it space-efficient for numerical data.
Binary: Occasionally used for fixed length integers, encoded as 1 or 2 byte values in either little-endian or big-endian format, depending on the system’s requirements.

Variable or fixed length

A fixed length field always takes up the same number of bytes and padding is necessary to make sure the field fills its entire length. For example, amount fields are often 12 digits, right-justified, and padded with zeros—000000002412 represents $24.12. Variable length fields are preceded by a length prefix, so no padding is necessary, as the receiver first decodes the length indicator and then uses that to know how many bytes to extract for the field itself.

How a variable length indicator is encoded also depends on the content of the field itself: a numeric Acquiring Institution ID might for example be encoded as packed BCD, where 12 digits is encoded in 6 bytes, but the length indicator would still state the number of digits, 12, and not the number of bytes, 6. This creates an interesting situation for odd-length integers. Take the number 123 as an example: when serialized, it becomes the byte array [1, 35], represented in binary as 00000001 00100011. When we roundtrip this back, we end up with the value 0123 as we’re not able to differentiate between a 0 in the first nibble (half byte) and the padding-zero we used for 123. As such, it is necessary to incorporate the length indicator, which tells our encoder that the actual value length is supposed to be 3 digits so that we can trim away the first padding-zero.

Nested messages

While the standard defines core fields such as “transaction amount” and “merchant identifier,” the list of pre-defined fields in the original standard eventually became a limiting factor for card network feature development. To address this, the standard reserved certain “private use” fields that card networks could utilize to serialize custom data as needed. This is where the specifications really started to differ between networks, both in the data they chose to communicate but also in how each nested field was serialized. The original standard provided limited guidance on this topic, an oversight that later versions sought to address.

There are generally three main ways to serialize a nested message:

Tables: Each field is usually of fixed length and is always included, either with its actual value or replaced by a default placeholder value if empty.
Nested bitmap messages: Only present fields are serialized, using a simplified, fixed-length version of the top-level bitmap to indicate field presence.
Tag Length Value (TLV) messages: Each field is serialized as a tuple containing the field number (“tag”), the length of the field, and the field value. This format is defined by a separate standard, ISO 8825, which outlines the encoding rules from ASN.1.

How common each nested message type is varies from network to network. You might see American Express heavily use tables, while only Visa and China UnionPay make use of nested bitmap messages. Mastercard primarily sticks to Tag Length Value messages, a direction in which most of the card networks are slowly moving towards for all their new sub-fields.

Tables

The original nested message element is both the simplest and the most complex. In its simplest form, each sub-field is serialized sequentially, with no fields omitted, always resulting in a fixed number of bytes. This works fine for basic tables with a low number of fields but resulted in space inefficiencies for tables with a larger number of optional fields by having to send unnecessary padding characters for fields that were rarely present. Attempts to tweak the format to better support this and other scenarios introduced significant complexity, where the implementers would have likely been better off with a completely different sub-message type altogether.

This evolution reflects a common pattern in software development, where an implementation starts off as simple but gradually grows in complexity as extensions are added. In the end you’re left with a solution that is more complicated to implement for clients than what a new and separate concept altogether would have been.

We can see the basic table format at display in one of the original fields, field 43 Card Acceptor⁰ Name or Location:

Variable tables

Each table takes up a predefined number of bytes and is always present, as receivers expect to parse each field in order. To omit the city name in the example above we would instead fill it with 13 spaces, resulting in the same overall size of 40 bytes. This is an inefficient approach if the city name is frequently omitted, forcing participants to transmit empty spaces to indicate the absence of data. Instead, in cases where a number of the sub-fields in a table are optional, implementations might let the sender omit sub-fields as long as they omit all the subsequent sub-fields in the table. Referring to the sub-fields in the example below as A, B, and C, you would be able to send the combinations of: only A, only A and B, or A, B, and C altogether. This type of “telescoping” is only possible when the table is preceded by a variable length indicator, communicating to the recipient how many bytes they should expect to read for the field, such as 25 bytes (A), 38 bytes (A + B), or 40 bytes (A + B + C).

This concept is also used to nest sub-messages within sub-messages, as shown in the Additional Amounts field below, where we can serialize up to 6 additional amounts of 20 bytes each:

A similar extension happens when we want to support having one of the sub-fields take up a variable amount of space. Going back to our Card Acceptor Name or Location table, if we wanted to support a card acceptor name sub-field of up to 200 characters, the original approach would require all participants to pad the value with spaces up to the maximum length of 200 characters. This method, while functional, is inefficient for a standard that greatly values its frugal use of space.

To address this, some networks solve the issue for fields like addresses by placing the variable-length sub-field at the end of the table. This allows the receiver to simply read the remainder of the field without requiring padding, effectively eliminating unnecessary overhead. This method only allows a single variable length sub-field per table, however.

Nibble tables

Some tables consist entirely of numeric fields encoded with packed BCD. This is the case with Visa’s Additional Point of Sale Information field, where most of the fields only consist of single-digit enums. If we were to serialize these as usual, we would end up with an entire byte for each separate field, with the first 4 bits of each byte wasted on zeros. “Obviously” an egregious inefficiency, the specification instead defines that each single-digit field should occupy only one nibble, or half a byte.

Serialized, this would look like:

Byte 1: terminal type for the first 4 bits, terminal entry capability for the last 4 bits
Byte 2: chip condition code for the first 4 bits, special condition indicator for the last 4
…and so on.

Nested bitmap messages

Most of the complexity discussed earlier comes from trying to omit certain sub-fields without having to waste space on empty characters to communicate that a field has been omitted. A nested bitmap message solves this problem by including a bitmap before the elements, communicating to the recipient which fields are present and which are omitted. This is identical to how the top-level message itself is serialized, with the distinction that nested sub-level message bitmaps are generally shorter and of fixed length (e.g., 8 bytes to allow 64 bits/fields).

This is an improvement over tables in that it eliminates the need to serialize empty values entirely, saving space and simplifying the interpretation of fields. There is no ambiguity about whether an empty value indicates omission or carries an actual value (e.g., a zero amount).

It is also an improvement in retaining backward compatibility. For example, you could write a parser where you ignore any new bitmap fields that you’ve yet to implement, allowing networks to add new fields up to the maximum capacity of the bitmap (e.g., 64 fields for 8 bytes). However, this is generally not how the networks operate, as the addition of a new field is considered a significant change that requires advance notice to clients.

Tag-length value messages

Later versions of the ISO 8583 standard incorporated parts of a separate standard altogether, ISO 8825, for use in nested sub-messages. This approach is so robust that it completely removes the need for other nested message types like tables and bitmap messages. In this format, each field is serialized as a tuple consisting of a tag, the length of the field, and the field value itself. Similar to the nested bitmap messages this lets the sender omit any missing fields as the recipient can rely on the tag component to identify which sub-field is being parsed.

The TLV format is, unlike the other two message formats we’ve looked at, unordered. While the tags are defined in a specific order in the specification, the sender can choose to serialize each tag-length-value tuple however they want without causing issues for the recipient. This would not work for the nested bitmap field, where the recipient reads the bitmap to see which fields (e.g., field 1, 3, and 5) are present and then expects the corresponding data to follow in that order. A tag-length-value parser, on the other hand, would read the tag first and use that to know which field is being parsed.

Tag-length value parsers are slightly more involved to implement but offer the most flexibility for networks: participants are expected to handle new sub-fields gracefully.

Tag and length formatting

Both the tag and length components are encoded in a way where the recipient can determine how many bytes are used for each component from the value of the initial byte. The tag, for example, only sets the last 5 bits in the first byte if a subsequent byte is necessary.

Hierarchy

Generally tag-length value messages are structured as two layers of messages: the top level is called a “dataset” where the number of bytes used by the tag and length components are fixed, while the lower level of tag-length value fields rely on the variable format for both the tag and length indicators. This provides ample room for adding more fields.

Framing

ISO 8583 messages are generally sent over long-lived TCP sockets, as described in “Visa: half a century of high availability”. As such, there needs to be a layer of framing around the messages so that the recipient knows where one ISO 8583 message ends and another begins in a stream of TCP packets. This is usually done with a simple length indicator, preceding the ISO 8583 message with a 4-byte indicator that informs the recipient of how many bytes they should read for the ISO 8583 message itself.

Network-specific header

Some of the card networks, such as Visa, also include a header between the framing Message Length Header and the ISO 8583 message itself. This generally consists of meta information about the message itself, such as where it was sent from and where it is to be delivered, and whether the network rejected it with any errors.

Building parsers

Parsing a basic ISO 8583 message is straightforward and generally only requires the implementation of a bitmap parser and a length definition for each field to be able to handle the primitive elements at the top level. A lot of the complexity comes from correctly handling the various types of nested sub-messages and the subtle differences between each card network’s implementation. A useful technique for tackling this complexity is to define the core building blocks needed to declaratively compose a message, as opposed to imperatively implementing each of the different field types on their own.

At Increase we write Ruby and make heavy use of the Sorbet type system. As such we define our ISO 8583 parsers with T::Struct classes from Sorbet, which gives us a type-safe message class after parsing.

class Message < T::Struct
  const :primary_account_number,
        T.nilable(String),
        extra:
          Field.build(
            message: Field::Message::Bitmap.new(index: 2),
            encoding: Field::Encoding::BCD,
            length:
              Field::Length::Variable.new(
                bytes: Field::Length::Variable::Bytes::ONE,
                encoding: Field::Encoding::BINARY,
              ),
          )

  const :processing_code,
        T.nilable(ProcessingCode),
        extra:
          Field.build(
            message: Field::Message::Bitmap.new(index: 3),
            length: Field::Length::Fixed.new(size: 3),
          )

  const :amount_transaction,
        T.nilable(Integer),
        extra:
          Field.build(
            message: Field::Message::Bitmap.new(index: 4),
            encoding: Field::Encoding::BCD,
            length: Field::Length::Fixed.new(size: 12),
          )

  const :transmission_date_and_time,
        T.nilable(Time),
        extra:
          Field.build(
            message: Field::Message::Bitmap.new(index: 7),
            transform: Field::Transform::Time.new(format: '%m%d%H%M%S'),
            length: Field::Length::Fixed.new(size: 10),
            encoding: Field::Encoding::BCD,
          )

  const :response_code,
        T.nilable(ResponseCode),
        extra:
          Field.build(
            message: Field::Message::Bitmap.new(index: 39),
            encoding: Field::Encoding::EBCDIC,
            length: Field::Length::Fixed.new(size: 2),
          )
end

This makes it easy to map from the specifications provided by the card networks to a declarative parser implementation. It is useful to try to define sane defaults—a fixed-length Integer type is by default right-justified and padded with zeros, but if you needed to override it you could do so:

const :amount_settlement,
      T.nilable(Integer),
      extra:
        Field.build(
          message: Field::Message::Bitmap.new(index: 5),
          encoding: Field::Encoding::BCD,
          length: Field::Length::Fixed.new(size: 12),
          padding:
            Field::Padding.new(
              character: Field::Padding::Character::SPACE,
              justification: Field::Padding::Justification::LEFT,
            ),
        )

Similarly, we define nested sub-messages with other T::Structs and leave room for configuration where functionality deviates from network to network:

class VerificationAndTokenData < T::Struct
  sig { override.returns(MessageTransform[VerificationAndTokenData]) }
  def self.transform
    TagLengthValue::MessageTransform.new(
      struct_class: self,
      tag_transform:
        TagLengthValue::FixedTagTransform.new(
          bytes: TagLengthValue::FixedTagTransform::Bytes::ONE,
        ),
      length_transform:
        TagLengthValue::FixedLengthTransform.new(
          bytes: TagLengthValue::FixedLengthTransform::Bytes::TWO,
        ),
    )
  end

  class VerificationData < T::Struct
    sig { override.returns(MessageTransform[VerificationData]) }
    def self.transform
      TagLengthValue::MessageTransform.new(
        struct_class: self,
        tag_transform: TagLengthValue::VariableTagTransform.new,
        length_transform: TagLengthValue::VariableLengthTransform.new,
      )
    end

    const :postal_code,
          T.nilable(String),
          extra:
            Field.build(
              encoding: Field::Encoding::EBCDIC,
              message: Field::Message::TagLengthValue.new(tag: 0xC0),
            )

    const :street_address,
          T.nilable(String),
          extra:
            Field.build(
              encoding: Field::Encoding::EBCDIC,
              message: Field::Message::TagLengthValue.new(tag: 0xCF),
            )
  end

  const :verification_data,
        T.nilable(VerificationData),
        extra:
          Field.build(
            message: Field::Message::TagLengthValue.new(tag: 0x66),

  # ...

  const :missing_tags, T.nilable(T::Hash[String, String]), default: {}
end

Error handling

The missing_tags fields in the tag-length-value messages above store a hash map of any tags we’ve yet to implement and ensure that messages still round-trip correctly without blowing up for new tags. This type of future-proofing is generally only required for tag-length-value messages, but gracefully handling local errors in sub-messages is a useful concept to apply to the rest of the parser as well. While the card networks do validate the overall format of the message, there is lots of room for subtle errors that do not result in rejections at the network level.

This makes graceful error handling especially crucial for issuer processors, who receive authorization requests from a large number of acquirers across the world. Failing to parse one of these messages means a decline for your cardholder, an especially frustrating experience when you’re trying to pay for a bill in person. It is also a useful concept for acquiring processors, however, where you often end up seeing incompliant sub-fields in the responses to your messages.

To gracefully handle errors in nested sub-fields you partition the byte stream you’re parsing such that you can continue handling the next field if an error happens in the field before. Take the Additional Point of Sale Information table from earlier as an example: each of these fields are enumerations, and you might wish to map them to an enumeration in your programming language instead of dealing with the raw network values (usually integers). If you do so you will eventually see an enumeration you have yet to handle, at which point your parser should be able to record it as a partial error and continue with the next field.

An important nuance to keep in mind here is that we still need to ensure that we serialize the table back to a reasonable value (often called round-tripping), especially if it’s a table the sender expects to receive mirrored back in the response. Simply omitting the value you failed to parse altogether would result in a shorter overall length for the table, and so you’ll need to either replace the unknown value with a placeholder—such as a space or a zero, depending on the content—or keep hold of the raw value you were unable to parse to put it back in the message afterwards.

Moving up one level you can follow a similar principle for an entire sub-message itself. If we’ve parsed two fields in a tag-length-value message correctly but then reach an error trying to interpret the length indicator of the next tag, we’ll need to throw out the rest of the sub-message and keep what we parsed so far, even if it means potentially throwing away sub-fields that would’ve followed after the faulty length indicator.

Finally, at the very top level there are errors that we just can’t recover from. If we fail to parse the length indicator for one of the top-level fields we’ll have no way to parse the rest of the message and it is likely critical enough that we shouldn’t attempt to use what we have so far. This is the type of decision you want to make for every part of your parser that can possibly fail—have we reached a fatal point of no return or is there a way we can gracefully continue to parse the rest of the message, despite the error we just experienced?

Conclusion

Throughout this article we’ve looked at some of the interesting intricacies that arise when parsing ISO 8583 messages, and discussed how they came to be from the initial ISO 8583 standard defined in 1987. When you use Increase for Programmatic Card Processing we take care of parsing the card network messages for you so that you can focus on building your product. We do so in a way that avoids hiding or obfuscating details, as described in our “No Abstractions: an Increase API design principle” blog post. If this approach resonates with you, contact our sales team to talk about using Increase as your issuer processor, or check out our API documentation.

Notes

Card Acceptor is usually synonymous with merchant: an entity that accepts cards for payments. ↩

Cash reconciliation: Aligning transaction activity with the Federal Reserve's data

Louis Sobel — Thu, 21 Nov 2024 00:00:00 GMT

Increase operates as a parallel core for our bank partners. We connect directly to the Federal Reserve and process wires, ACH transfers, and checks using a dedicated routing number. An important associated responsibility is to reconcile the activity in our systems with the cash movement at the Federal Reserve.

While banks are responsible for ledgering the activity of their customers, the Federal Reserve is the source of truth on where dollars actually sit. Ensuring precise reconciliation between bank records and the Federal Reserve’s data is essential to maintain a clear and accurate view of customer funds. Each day, we compare reports provided by the Federal Reserve with our independently generated expectations of those reports to ensure alignment.

Federal Reserve Accounts

Every chartered financial institution is eligible for an account at their regional Federal Reserve Bank. In many ways, this account is just like any other bank account. There’s an account number (generally the bank’s main routing number), an interest rate (the Interest on Reserve Balances), an API (ACH, wires, etc), a web interface, and statements. The Federal Reserve makes these statements available in a machine-readable file they call Financial Institution Reconcilement Data.

This file has detailed information about debits and credits posting to the account. If a bank has multiple routing numbers, the Financial Institution Reconcilement Data separates activity by routing number. There are many different transaction codes, ranging from 10010 (“Transfer of Funds”, used for wires), to 63010 (“Coin Transaction”), to 84710 (“Dodd Frank Assessment Fee”)—you can download a full list of transaction codes from the Federal Reserve.

Expectations

To support reconciling Increase activity to this Financial Institution Reconcilement Data, we generate what we call an “Expected Cash Transaction Contribution” whenever something happens in our system that we expect to contribute to some cash transaction. We check daily that our expectations match the actual reality of the Federal Reserve reporting in both directions:

All expectations correspond to reported cash movement
All reported cash movement corresponds to expectations

This means that our code needs to deeply understand and model how the Federal Reserve works to generate expectations that can later be matched to the actual reporting. For wires, this is straightforward: there is one Financial Institution Reconcilement Data (FIRD) transaction for each incoming / outgoing wire. This transaction includes the wire’s Input Message Accountability Data (IMAD), which uniquely identifies it. We generate an expectation including the IMAD that is later matched to the actual reporting through a point-lookup.

Things are substantially more complicated for ACH. Whereas there is one FIRD transaction per wire, for ACH the reported transactions are aggregates of many underlying ACH entries, and not just a single aggregate. The FIRD transaction an ACH entry will end up contributing to depends on multiple factors.

Whether the entry was a credit or debit
Whether the entry was a forward or return
Whether the entry was originated or received
Whether the entry was same-day or future-dated
The specific same-day window it settled in or the date the entry was processed (for a future-dated entry). “Date” here—of course—referring not to a calendar date in Eastern Time or UTC but rather an “ACH–date” which runs 2:15AM Eastern Time to 2:15AM Eastern Time.

Our logic that generates expectations considers all this. We reconcile an ACH FIRD transaction by finding the many expected contributions that correspond to it, adding up their amounts, and making sure the sum matches the aggregated amount reported by the Federal Reserve.

The complexity of the Federal Reserve’s check settlement service, Check 21, is somewhere between ACH and wires. There are fewer transaction codes — 4 rather than 26. But we need to account for edge cases in how the same-day funds availability cutoffs are defined. For example, there can be different same-day deadlines for checks drawn on routing numbers starting with “1214” or “3214”, or in lists published by the Federal Reserve.

Operating confidence

While there’s a lot of complexity to encode, it’s all complexity essential to accurately predicting how events in our system impact cash movement at the Federal Reserve. At Increase, we love getting deep into these details, understanding them, then automating that understanding. Reconciling these predictions to the actual reporting gives us confidence that our modeling is correct and that our system is working as expected.

We have alerts that continuously monitor the reconciliation process, ensuring that our expectations align with actual outcomes. While we have numerous other alerts that would trigger if, for instance, we failed to process an incoming ACH file or a wire we think was sent was actually rejected, these alerts provide an additional control and layer of detection in case those earlier mechanisms miss something.

Among the many reconciliations that we perform, this one confirms that we are correctly performing a critical role of a bank core: interacting with our partner banks’ Federal Reserve accounts. By rigorously matching every expected transaction with the Federal Reserve’s reporting, we’re able to identify discrepancies instantly, confirm the accuracy of our models, and ensure seamless operation for our partners. This ongoing alignment doesn’t just give us operational confidence—it embodies our commitment to transparency and reliability, setting a high standard for how banking infrastructure should operate.

At Increase, we believe that mastering the details and automating with precision is the way to advance how financial systems connect and operate.

2024 Q3 Newsletter

Mon, 30 Sep 2024 00:00:00 GMT

September 30, 2024

You can now subscribe to an RSS feed of our changelog.
card_decline and real_time_decision.card_authorization resources now have the direction field populated to signal if it is a refund authorization or a regular authorization.

September 23, 2024

You can now download bank letters and funding instructions from the Account detail views in the Dashboard.

September 6, 2024

You can now view a timeline of events for Declined Transactions in the Dashboard.
You can now view a timeline of events for Inbound Real-Time Payments in the Dashboard.
Inbound Real-Time Payments are now exposed by the API , letting you list and get Transfers.
Simulating an inbound RTP will now return an Inbound Real-Time Payments Transfer object

August 16, 2024

You can now view the inbound_funds_hold sub-resource on the ACH Transfer object. This is relevant for ACH debit transfers and will contain details of the hold, including the ID of the Pending Transaction and when funds will be released.
Cards can now be used with Samsung Pay. You can view the requestor in the token_requestor attribute .
Creating reversals for ACH Transfers is now out of beta in the Dashboard.
You will now receive daily emails for any control failures.

August 9, 2024

You can now configure the email preferences for your Group in the Dashboard Settings .
You can now export Transactions by Program.

July 26, 2024

You can now view the merchant_state and merchant_postal_code on various card authorization sub-resources.

July 12, 2024

The Dashboard now supports both light and dark modes. You can configure your theme in Settings .
You can now mark Inbound Check Deposits as “Returned” with an accompanying reason.

July 5, 2024

Inbound ACH Transfers now resolve on their effective date. This means that the Inbound ACH Transfer will still be created as soon as Increase receives it, but the Transaction will be created according to the settlement schedule for the effective date. You can use the automatically_resolves_at field to see when the Transaction will be created.

Automated invariant monitoring

Darragh Buckley — Mon, 09 Sep 2024 00:00:00 GMT

In 2012, Stripe had an incident where a file sent to a financial partner wasn’t acknowledged. This went unnoticed, leading to a delay in transferring what seemed like a significant amount of money at the time. During the debrief, it became clear that we needed more robust automated monitoring and alerting for our financial partner integrations. In the next day or so, Patrick and Siddarth built an invariant monitor.

The invariant monitor was a lightweight framework that enabled engineers to write code that continuously tracked certain database conditions to ensure they always held true. If something went wrong, it would raise an alert. It was loosely inspired by Nagios but written as application code that runs in the context of the rest of the codebase. Examples of the conditions that were monitored were:

Has a money movement file been generated every day?
Has every generated file been submitted to a partner?
Has every submitted file been acknowledged by that partner within the expected timeframe?

The invariant monitor became even more useful when Jeremy built automated monitoring into the frameworks for file generation, submission, retrieval, and storage.

This tool massively improved operations. It let us codify and monitor our assumptions. It was like seeing automated testing for the first time—it felt so clearly the right approach and so necessary that it was surprising every company didn’t have a similar tool.

At Increase, this kind of monitoring was one of the first things we built. We call it Checker, with the individual monitoring rules known as Checks. (We’re not particularly creative with names.)

Here’s what a Check looks like:

check 'Database backup test restorations are running',
      frequency: Frequency::EVERY_SIX_HOURS do
  DatabaseBackupRestoration.exists?(
    created_at: (Time.now - 2.days)..,
    status: DatabaseBackupRestoration::Status::DONE,
  )
end

This alerts if we’ve failed to restore our database backups within the last two days. It’s reassuring to know that we’d know if there’s something wrong with our database backups before we need them.

Like Stripe, we’ve built automated Checks into our frameworks. One particularly useful pattern has been implementing automated Checks for our state machines. These Checks monitor that transitory states don’t last too long. For example, any mail item received for our new lockbox feature shouldn’t have a status of PENDING_PROCESSING for more than a day. If it does, we’re alerted.

Here’s the code:

class InboundMailItem < AbstractModel
  attribute :status,
            default: Status::PENDING_PROCESSING,
            transient_values: [Status::PENDING_PROCESSING],
            terminal_values: [Status::PROCESSED, Status::REJECTED]
end

Engineers mostly don’t have to think about Checks when building features. attribute is the default way to declare a model property in our Object-Relational Mapper so engineers typically get this monitoring for free.

We use Checks broadly. Since Checks are code, they can make API calls and monitor external services too. Security, for example, has a Check to ensure no Dropbox files are accidentally shared. And Compliance has one to track sanction screening lists. Whenever a person manually monitors something, we try to turn it into a Check. (That way they can go on vacation.)

We’ve also built tooling and processes around our Checks. If you’re considering building your own, here are a few things we’ve learned:

As with any monitoring, be careful with your signal. A flappy Check is worse than no Check.
Checks can have different priorities and alerting. A Check for an unexpectedly missing ACH file might page an on-call engineer while a Check that our physical card inventory is getting low might just create a ticket.
Each Check should have a responsible team or person.
Have a suppression mechanism to help with long-failing Checks.
Similar to tests, ensure Checks are easy to write. Also similar to tests, periodic pruning helps.
Have tests for your Checks. These need to include both the success and failure cases.

If ensuring people can sleep well at night is the kind of engineering you enjoy, you might also enjoy jobs@increase.com.

Visa: half a century of high availability

Martin Ek — Fri, 23 Aug 2024 00:00:00 GMT

From the Fresno drop in 1958 and through Visa’s first 15 years of existence, an authorization with a Visa card was processed by having the merchant call either the cardholder’s bank, if the card was regional, or a switching center to be forwarded onto the bank if it was not. In the early 70s, the overhead of this reached a breaking point and Visa set out to build what would become known as “BankAmericard Authorization System Experimental (BASE)“—an electronic authorization system linking the Visa member banks with merchants or their acquiring centers through a central switching system. While the protocols and implementation details look drastically different 50 years later, many of the core principles from BASE still stand today: a centralized switching system connecting acquirers to issuers through leased line connectivity to both sides, with redundancy built in at each step of the process⁰.

Increase’s authorization connectivity with Visa is built on the same principle of redundancy: each of our data centers connect to each of Visa’s two data centers through at least two separate circuits from at least two routers. This in turn connects to our cloud provider through at least two regions. Every layer maintains redundancy of each other: both of our physical data centers can talk to both of Visa’s data centers and both of our cloud regions can reach both of our physical locations.

This summarizes the high-level architecture of Increase’s redundant connectivity with Visa. The rest of the article digs deeper into the details of how the specific messages transmitted over the Visa network work.

Visa authorization messages

Visa’s BASE I system predates HTTP and the internet by almost two decades, but the way the contents of an authorization message transmit from an acquirer to an issuer is intuitive even from today’s point of view. Unlike HTTP 1.1, where a corresponding response always has to follow serially on a TCP socket after the request, Visa’s authorization system is configurable to allow responses to be sent through almost any live connection the recipient has, resembling HTTP 2’s multiplexing with a unique identifier in each message. For Visa, the messages follow the ISO 8583 standard¹ but are preceded by a 4-byte message length header that indicates the size of the message that is to follow. After the 4-byte message length header follows a routing header that includes information about where the message is to be routed, which then is followed by the message itself.

The ISO 8583 standard defines the overall structure of the message but leaves the underlying content to be defined by each card network. From a quick glance they share similar principles: a 4-digit Message Type Indicator that states the purpose of the message and its direction (e.g., 0100 is an Authorization Request and 0110 is an Authorization Response), a bitmap that indicates which fields are present, followed by each present field serialized in order. Unlike a message protocol like Google’s Protocol Buffers, deserializing an ISO 8583 message correctly is impossible without first having implemented a parser to a specification. The parser tells the recipient how to handle each separate field—some fields might be simple fixed-length numeric fields, while others will be complicated deeply nested variable length fields.

Initiating sessions

Both sides of the table, the acquiring processors and the issuer processors, sign on to the Visa network by opening a TCP connection and sending a sign-on message that identifies the specific authorization “station” that they represent. As an issuer processor, we sign on to our stations from our cloud-hosted Message Processor services and wait for Visa to relay us messages from acquiring processors relevant to our cards. When we receive a message, we parse it, redact out sensitive details from a Payment Card Industry Data Security Standards (PCI-DSS) perspective (such as card numbers), and pass the message on to the rest of our authorization processing systems for further checks.

When we’re ready to respond, we send a similar looking message back with a specific numeric identifier (field 37, “Retrieval Reference Number”) set to the same value as we received in the request. This then gets passed back to the acquiring processor, which in turn will match the incoming response to the outgoing pending request they have and provide an answer to the merchant and the cardholder who is waiting at the point of sale.

From cloud to physical

From our cloud providers, we connect to the routers hosted in our physical data centers through Cloud Interconnect. Each cloud region maps to a physical data center in regional proximity. However, all of our cloud providers can reach all of our physical data centers and vice versa. From here, our routers connect to a set of Visa-owned routers in the same data center, which in turn handles communication with another set of routers in Visa’s data center.

Avoiding the fragility of the public internet, the communication between the Visa routers in our data centers and the Visa Message Gateways in Visa’s own data centers happen using a combination of leased circuits from redundant telecom providers and Visa’s Multiprotocol Label Switching (MPLS) network. In some ways this has more of a resemblance to the point-to-point behavior observed in analog phone lines than to the packet routed system of the public internet. Instead of labeling a packet with the destination and letting the individual hops decide how the packet gets there, the route through the network is defined ahead of time and the packets state which path they expect to take.

Visa’s data centers

Outside of European traffic, all Visa authorizations eventually end up in either of Visa’s two US data centers: central and east. These are both active at any time and transactions fall back to either seamlessly. Similar to how we redundantly connect to both of our data centers, each of the two locations also connect to each other and relay messages back and forth when necessary. When Visa receives a message from an acquirer processor, its main responsibility is figuring out where to send it by looking at the first digits of the card number and figuring out which issuer processor is set up to handle it.

As Visa’s system has evolved from manual authorizations to modern redundant systems, it has maintained its foundational commitment to reliability and high availability. Increase’s architecture is built on these same principles, ensuring that transactions are processed securely, reliably, and promptly. If you’re looking to partner with an issuer processor that provides direct access to the Visa network, you can contact our sales team or learn more through our API.

Notes

Stearns, D: A History of the VISA Payment System, 1970 – 1984. ↩
https://en.wikipedia.org/wiki/ISO_8583 ↩

Increase: a modernized banking core

Thu, 01 Aug 2024 00:00:00 GMT

Bank cores

A bank core is one of those bedrock systems of modern society (birth registry, electronic healthcare records, air traffic control, etc) that we all want to see operate reliably and not be particularly exciting.

A bank core serves as the database and related logic responsible for maintaining the transactions and balances of a bank. It can also be responsible for services like account holder data, payment network interactions, and reconciliations. It is designed to be highly reliable and scalable while being in compliance with regulatory standards.

In the US, the most widely used bank core providers are FIS, Fiserv, and Jack Henry. The core providers themselves have many different cores⁰¹ targeting sizes or cohorts of financial institutions. In fact, there’s even an open source Apache core project, if you’re interested in seeing code².

Technical limitations

Many financial technology companies building products in partnership with banks run into technical constraints that start with bank cores. This is for a couple of reasons.

Many cores weren’t designed or built with programmatic interaction in mind. Even if a financial technology company integrates into a traditional core, the core was likely built with very different use-cases in mind and therefore very different assumptions. For example, it often takes a day to open a new bank account, and each account has a single account number as its primary identifier. Payments are typically sent via batch files, rather than via API. Visibility into transaction details is limited.

A bank could gain more technical flexibility and data visibility by converting to a more modernized core³. However, migrating from one core to another is a large project involving months of planning, as well as coordination with the Federal Reserve and other payment network operators. This also fails to solve for the challenges around programmatic data interaction between the core and the financial technology company; there’s substantial product work required to expose a sensible API to clients, and many modernized cores haven’t been designed with client needs in mind.

“Many cores weren’t designed or built with programmatic interaction in mind. Even if a financial technology company integrates into a traditional core, the core was likely built with very different use-cases in mind and therefore very different assumptions.”

To solve for client-facing APIs, a bank could partner with a banking-as-a-service or “middleware” provider. These providers do the heavy lifting of integrating to the bank’s traditional core, and offer abstracted account creation and money movement to financial technology companies via API. However, they’re still dependent on the traditional core for access to underlying network data and account structures. They can’t solve for limited data visibility and inflexible account structures.

Running a parallel core

One solution to this problem is running a parallel core. A financial institution can maintain its existing core while simultaneously adding a new core. The two cores can interact as necessary (either by exchanging data directly or separately interacting with upstream or downstream services).

This is what Increase does: we operate as a parallel core for our bank partners. We also expose functionality of the underlying depository rails via powerful APIs.

Increase allows bank partners to offer financial technology clients programmatic access to banking and card rails with flexible implementation structures and granular network details.

Flexible implementations

With Increase, banks can enable financial technology clients to synchronously provision Accounts. Every Account sits on Increase’s core and is able to receive and originate payments. Abstractions like virtual “accounts”—which can help with ledgering but have more limited functionality—aren’t necessary. Importantly, this also means the bank and the client work off a single system of record, and funds in each Account are always reconciled down the penny.

Banks may also offer many Account Numbers pointing to each Account. Clients can programmatically spin up unique Account Numbers to track and reconcile inbound payments into one Account.

“We operate as a parallel core for our bank partners. We also expose functionality of the underlying depository rails via powerful APIs.”

Fine grained network details

With direct connections to the US payment rails, Increase exposes all the details and functionality of the underlying financial network by API, without abstractions.

For example:

Every inbound wire allocated to an Account contains an Input Message Accountability Data (“IMAD”), a unique identifier assigned to each Fedwire payment made through the Federal Reserve. Details like this one often get obfuscated when there’s a human-run wire desk involved.
When an ACH Transfer is returned, we parse the network message from the Federal Reserve, correlate it to the original transfer, and create a new Transaction to reduce an Account’s balance. A client can immediately view the return details and instantly map each return to its initial Transaction.
We expose network updates in real-time. Originated ACH Transfers update when the transfer is submitted to the Federal Reserve, when the transfer is acknowledged by the Federal Reserve, and when it’s expected to settle with the recipient bank.

Your reaction to all this might range from amazement to ‘huh, that’s a neat little tidy-up I guess’ and either way, we agree. To the original observation that bank cores should be reliable and not particularly exciting, we strive to be lovingly boring. The US financial networks⁴⁵⁶⁷ have been around for a long time and offer robust functionality and detail for accounts and payments. Increase simply improves the last mile delivery.

Notes

Announcing Lockboxes: Programmatically deposit checks with your own virtual mailbox

Tue, 30 Jul 2024 00:00:00 GMT

Paper checks are a practical and widespread form of payment. Writing an amount and your signature on a slip of paper is easy to understand and simple to do. In 2023 alone, the Federal Reserve collected over $8.45 trillion in commercial checks⁰. Digital transfer mechanisms are growing, but the good-old-fashioned physical check is still relied upon and essential for many payment flows.

However, checks are slow and tedious to manage. They sometimes take weeks (or even months!) to be deposited after making it to the recipients’ mailbox. If you’re sending or depositing checks at scale, managing these slips of paper can be a significant headache. This is why we’ve built a fully digital check processing system.

Increase’s API and Dashboard allow efficient, programmatic access to mail checks, deposit check images, and — starting this month — host a virtual mailbox to accept payments in your designated check lockbox.

Lockboxes are the latest addition to our suite of check features. You can create unlimited mailing addresses and whenever a check is mailed to that address, we’ll create a Check Deposit and add the funds to your account. We’ll send you a webhook to keep you in the loop and you’ll have full access to accept or decline checks as they come in. We will even shred the checks once they’re processed.

Depending on your business, we recommend making one lockbox per invoice or one lockbox per customer relationship. This makes reconciliation between incoming funds and their revenue attribution much easier.

Increase’s commitment to No Abstractions means we give you full control over the network messages sent to Check 21, the Federal Reserve’s network for processing checks. That includes reading the raw TIFF images sent from other banks or controlling fraud by issuing return codes directly to your counterparty’s institution. All of Increase’s features are available in the API for programmatic, bulk actioning and in the Dashboard for one-off debugging as you build your application.

You can also send checks through Increase, either through our check printer under the hood, or by a third party fulfillment provider of your choice. Before the check gets deposited at the recipient bank, we surface critical details to you—including the arrival scan and depositing bank name—allowing you to review and decline the deposit attempt if necessary.

Increase’s check features allow our users fine grained control, high levels of visibility, and great fraud-fighting tools. Read more in our API or contact sales.

Notes

https://www.federalreserve.gov/paymentsystems/check_commcheckcolqtr.htm ↩

2024 Q2 Newsletter

Sun, 30 Jun 2024 00:00:00 GMT

June 21, 2024

You can now view check deposit images in the Dashboard.
Card disputes are now visible on Transaction timelines in the Dashboard.

June 14, 2024

You can now create Lockboxes to deposit checks automatically via the mail. Each Lockbox has a unique address and is associated with one of your Accounts.
You can now configure transfer approvals for the Dashboard and the API separately.

April 29, 2024

You can now view the presentment amount ( presentment_amount) and presentment currency ( presentment_currency) on Card Authorization and Card Decline resources in the API.
We now support single sign-on in the dashboard. Reach out if you’d like to set it up.

April 15, 2024

We’ve added documentation for Programs to our guides.

April 22, 2024

We’ve added an Inbound Check Deposit model to the API to surface check deposit attempts on originated checks.
We now publish an inbound_check_deposit.created webhook event that you can listen for to run custom evaluation logic for Inbound Check Deposits.

April 8, 2024

We’ve added more detail on when Transfers require approval in the Dashboard Money Movement flow.
We’ve added a Card Payment lifecycle guide.

April 1, 2024

We’ve added more detail to our Documentation Guides for ACH, Wires, Checks and Real Time Payments.

No Abstractions: an Increase API design principle

Jack Reed — Tue, 23 Apr 2024 00:00:00 GMT

API resources are the nouns of your API. Deciding how to name and model these nouns is arguably the hardest and most important part of designing an API. The resources you expose organize your users’ mental model of how your product works and what it can do. At Increase, our team has used a principle called “no abstractions” to help. What do we mean by this?

Much of our team came from Stripe, and when designing our API we considered the same values that have been successful there. Stripe excels at designing abstractions in their API — extracting the essential features of a complex domain into something their users can easily understand and work with. In their case this most notably means modeling payments across many different networks into an API resource called a PaymentIntent. For example, Visa and Mastercard have subtly different reason codes for why a chargeback can be initiated, but Stripe combines those codes into a single enum so that their users don’t need to consider the two networks separately.

This makes sense because many of Stripe’s users are early startups working on products totally unrelated to payments. They don’t necessarily know, or need to know, about the nuances of credit cards. They want to integrate Stripe quickly, get back to building their product, and stop thinking about payments.

“For Increase users, trying to hide the underlying complexity of these networks would irritate them, not simplify their lives.”

Increase’s users are not like this. They often have deep existing knowledge of payment networks, think about financial technology all the time, and come to us because of our direct network connections and the depth of integration that lets them build. They want to know exactly when the FedACH window closes and when transfers will land. They understand that setting a different Standard Entry Class code on an ACH transfer can result in different return timing. Trying to hide the underlying complexity of these networks (by, for example, modeling ACH transfers and wire transfers with a single API resource) would irritate them, not simplify their lives.

Early conversations with these users helped us articulate what we dubbed the “no abstractions” principle as we built the first version of our API. Some examples of the way this mindset has subsequently affected its design:

Real-world naming

Instead of inventing our own names for API resources and their attributes, we tend to use the vocabulary of the underlying networks. For example, the parameters we expose when making an ACH transfer via our API are named after fields in the Nacha specification.

Immutability

Similar to how we use network nomenclature, we try to model our resources after real-world events like an action taken or a message sent. This results in more of our API resources being immutable. An approach that’s worked well for our API is to take a cluster of these immutable resources (all of the network messages that can be sent as part of the ACH transfer lifecycle, for example) and group them together under a state machine “lifecycle object”. For example, the ach_transfer object in our API has a field called status that changes over time, and several immutable sub-objects that are created as the transfer moves through its lifecycle. A newly-minted ach_transfer object looks like:

{
  "id": "ach_transfer_abc123",
  "created_at": "2024-04-24T00:00:00+00:00",
  "amount": 1000,
  "status": "pending_approval",
  "approval": null,
  "submission": null,
  "acknowledgement": null
  // other fields omitted here for clarity
}

After that same transfer has moved through our pipeline and we’ve submitted it to FedACH, it looks like:

{
  "id": "ach_transfer_abc123",
  "created_at": "2024-04-24T00:00:00+00:00",
  "amount": 1000,
  "status": "submitted",
  // immutable, populated when the transfer is approved
  "approval": {
    "approved_by": "administrator@yourcompany.com",
    "approved_at": "2024-04-24T01:00:00+00:00"
  },
  // immutable, populated when the transfer is submitted
  "submission": {
    "trace_number": "058349238292834",
    "submitted_at": "2024-04-24T02:00:00+00:00"
  },
  // immutable, populated when the transfer is acknowledged
  "acknowledgement": {
    "acknowledged_at": "2024-04-24T03:00:00+00:00"
  }
  // other fields omitted for clarity
}

Separating resources by use case

If, for a given API resource, the set of actions a user can take on different instances of the resource varies a lot, we tend to split it into multiple resources. For example, the set of actions you can take on an originated ACH transfer is different (the complete opposite, really) than the actions you can take on a received ACH transfer, so we separate these into ach_transfer and inbound_ach_transfer resources.

This approach can make our API more verbose and intimidating at first glance — there are a lot of resources on the left-hand side of our documentation page! We think it makes things more predictable over the long-term, though.

Importantly, our engineering team has committed to this approach. When you design a complex API over several years, you make small incremental decisions all the time. Committing to foundational principles upfront has reduced the cognitive load for these decisions. For example, when sending a wire transfer to the Federal Reserve, there’s a required field called Input Message Accountability Data which serves as a globally-unique ID for that transfer. When building support for wire transfers, an engineer in an abstraction-heavy API might have to deliberate how to name this field in a “user-friendly” way — trace_number? reference_number? id? At Increase that hypothetical engineer names the field input_message_accountability_data and moves on. When an Increase user encounters this field for the first time, while it might not be the most immediately recognizable name at first, it helps them understand immediately how this maps to the underlying system.

No Abstractions isn’t right for every API, but considering the level of abstraction that’s appropriate for the developers integrating against it is a valuable exercise. This will depend on their level of experience working with your product domain and the amount of energy they’ll be committing to the integration, among other things. If you’re building an abstraction-heavy API, be prepared to think hard before adding new features. If you’re building an abstraction-light API, commit to it and resist the temptation to add abstractions when it comes along.

2024 Q1 Newsletter

Sun, 31 Mar 2024 00:00:00 GMT

March 25, 2024

We now expose Program ID in the Account APIs.

March 18, 2024

Visa Advanced Authorization fraud scores are available for all card authorizations in the Dashboard and API under network_risk_score.
Increase can now automatically sync your Accounts and Transactions to Quickbooks Online.
We’ve removed the unused Submitted status from Check Transfer Documentation .

March 11, 2024

We’ve updated our Dashboard permissions to provide more granular control. You can access team permissions in Settings .
You can now assign more specialized roles when inviting teammates.
You can now configure Transfer approvals independently for each Program.

March 4, 2024

We’ve polished a number of our views in the Dashboard to follow a more standardized pattern for increased predictability on navigation.

February 26, 2024

You can now update the industry code for a corporate Entity.

February 19, 2024

You can now upload and update Complaints in the Dashboard .
We’ve introduced a new Dashboard based flow for reporting Unusual Activity Reports .

February 12, 2024

You can now order physical versions of your Increase cards in the API and in the Dashboard Card detail view by using the ‘Ship physical card button’ on any cards you’ve created.
You can now view structured ACH Addenda in the Dashboard .

February 05, 2024

We’ve exposed canceled Transfer Schedules in the Dashboard .

January 29, 2024

We’ve added a guide to Idempotency Keys .

January 22, 2024

We’ve added an Inbound Wire Transfer API to allow viewing and reconciling Inbound Wire Transfers.
You can now set your Program’s billing account in the dashboard by clicking into the Fee Plan detail view.
We’ve added command palette search functionality to the Dashboard.

January 15, 2024

We’ve added documentation on ACH Authorizations.
You can now view Inbound Wire Transfer timeline details on Transaction detail views in the Dashboard.
We’ve added more validation on CSV compliance report updates in the Dashboard.
We’ve updated our status page’s FedACH Schedule display for improved readability.

January 8, 2024

You can now favorite External Accounts in the Dashboard.
Fees and Fee Plans are now visible in the Dashboard.
You can now upload Vendor Lists as CSVs in the Dashboard.

How CapitalOS built their spend management platform on Increase

Wed, 06 Mar 2024 00:00:00 GMT

CapitalOS offers embedded spend management solutions for B2B platforms looking to launch card-based products for their users. As B2B platforms increasingly become the operating system for small businesses, they’re uniquely positioned to save time and money for their users through smart spend management.

How depository placement networks provide extended FDIC coverage

Sam Ballantyne — Thu, 25 Jan 2024 00:00:00 GMT

Increase and our bank partners now offer access to Federal Deposit Insurance Corporation (“FDIC”) coverage on deposits of more than $250,000. This works through our connection to a deposit placement network offered by IntraFi. You can place deposits using IntraFi’s ICS service via Increase’s Dashboard or API. Enrollment does not impact access to your funds.

If you’re in a hurry, that’s all you need to know. Deposit placement networks are a fascinating topic, however. The rest of this article dives into why this feature exists and how it works.

Silicon Valley Bank

On Friday, March 10, 2023, California regulators closed Silicon Valley Bank and appointed the FDIC as receiver, which issued a press release:

All insured depositors will have full access to their insured deposits no later than Monday morning, March 13, 2023. The FDIC will pay uninsured depositors an advance dividend within the next week. Uninsured depositors will receive a receivership certificate for the remaining amount of their uninsured funds. As the FDIC sells the assets of Silicon Valley Bank, future dividend payments may be made to uninsured depositors.

Unusual to this closure was the percentage of uninsured deposits: 93.9%. Depositors rushed to wire their funds out. At 6:24pm on Friday evening, a message came in extending the Fedwire window by 30 minutes:

The deadline was extended by 30 minutes eight times that evening, then by 15 minutes three more times, until it finally closed at 11:45pm.

The confusion continued over the weekend. The Silicon Valley Bank web portal started disallowing transfers. Alarmism circulated online. A news story on Sunday, March 12, reported, “Just 30% of uninsured SVB deposits could be available Monday as the FDIC gears up for a long and drawn-out sale process: sources.”

Bank failures

While Silicon Valley Bank’s failure happened quickly, it certainly wasn’t novel.

The Federal Deposit Insurance Corporation is well-named. As you might expect, it was founded in the 1930s when bank failures and bank runs were common. It aims to solve the runs, not the failures. It does so by guaranteeing your first $250,000 of deposits at a single bank. It’s funded by an annual levy on insured banks.

[Note: Interestingly, the insurance is per ownership category, per account holder, per institution. Checking accounts, savings accounts and CDs are treated as one category; retirement accounts are another; trust accounts another; employee benefit accounts yet another. Ownership categories are well documented.]

The amount insured was originally $2500 and has been raised gradually since then, most recently from $100,000 in 2008.

Today, bank failures are rare. Of the 4,645 FDIC-insured banks in the United States, there were zero failures in 2021 and 2022. But as you’re likely aware, there were 5 failures in 2023, including Silicon Valley Bank, First Republic Bank and Signature Bank.

Silicon Valley Bank’s failure was unique in that the vast majority of deposits there were uninsured (93.9%). Since then, there’s been a resurgence of attention on FDIC insurance limits, and how to protect funds above the limit.

Deposit networks, explained

If you’re storing funds above the limit, you’re likely interested in ways to insure them. In theory, you could get yourself multiples of $250,000 in deposit coverage by opening accounts at 2, 3 or even 400 banks. This would be a hassle. A startup CFO might spend all day on the phone with different banks putting together instructions to wire $3M.

“The swapped deposits ensure customers have access to additional FDIC insurance without the inconvenience of maintaining accounts at multiple banks.”

Suppose she has an idea: her fellow CFOs also have large deposits parked at the same banks. What if, operationally, they could each do business at their primary bank, and simply swap each other’s deposits? You have each bank place their deposits at several other banks in a placement network, with FDIC insurance up to $250,000 available at each. A bank that placed a large deposit through the network could also receive deposits in the same amount.

This is roughly how reciprocal deposits work. The swapped deposits ensure customers have access to additional FDIC insurance without the inconvenience of maintaining accounts at multiple banks. From the depositor’s perspective, everything is seamless: you can still access all the funds at your bank even if in the background some of those funds are “swapped” to another institution. You’re just better insured.

[Note: Until 2018, reciprocal deposits were considered brokered deposits, which are subject to different rules. Congress intervened, and now most reciprocal deposits are considered non-brokered.]

Increase’s implementation of this is transparent. You can see in the Dashboard which banks are holding deposits that have been placed for you.

The deposit network will only ever place funds for a depositor up to the current FDIC insurance limit at any other single institution. Of course, it’s possible that you already have funds stored at one or more other banks. To ensure that your funds held there are still insured, it’s straightforward to exclude financial institutions where you’re already storing funds.

Are uninsured deposits really uninsured?

When regulators announced Silicon Valley Bank’s closure on Friday evening, it made clear that insured and uninsured deposits would be treated separately. But that didn’t end up being the case: over the weekend, federal regulators decided to invoke the systemic risk exception, which protected uninsured deposits.

Because of this, you may assume your deposits will be protected even above insurance limits. The regulators make no assurances on that point. Past performance is no guarantee of future results.

The FDIC itself has reviewed insurance limits. It issued a report that considered various options, including changing limits or abolishing them. Instead, the FDIC seems to be leaning towards targeting insurance at specific account types — specifically business payment accounts. However, any changes to deposit insurance would require congressional action.

So where does that leave us?

The FDIC insures funds up to $250,000, per ownership category, per account holder, per institution. In the event of a bank failure, uninsured deposits could be safe. Another institution might step in to acquire all deposits, or federal regulators could invoke the systemic risk exception again. But there is no guarantee either of these things will happen.

That’s why we’re offering access to reciprocal deposits. It’s a way to obtain more peace of mind with access to additional insurance for more of your balances without impacting your operational access to funds. This is all now available in the Increase Dashboard and API.

Deposit placement through IntraFi Cash Service (“ICS”) is subject to the terms, conditions, and disclosures in applicable agreements.

How we work

Jamshed Vesuna — Wed, 10 Jan 2024 00:00:00 GMT

We first wrote an internal culture document at Increase on 2019-10-09. It was labeled as a draft since we weren’t sure what principles would hold true as we scaled. Now, 4 years later, we’ve found the way that we work allows us to process tens of billions in payments. Internally, this document will always remain a draft.

The central tenet of our culture is empowerment. It drives the way we make decisions, share knowledge, and make changes. It allows us to move with urgency. Ownership, transparency, and trust are key underpinnings for empowerment.

Ownership

At Increase, we make decisions by owner, not consensus. There is a single decision maker for almost every decision: technical design, product pricing, hiring, and third party integrations to name a few. It ensures that one person is responsible for the ultimate outcome. While the owner may not initially have all the information they need, it’s their job to solicit feedback and move us forward. We frequently use decision timeouts with a default decision to ensure owners aren’t blocked and to allow others to provide time-boxed input. We’ve found this model to scale well with our organization.

Transparency

A necessary pre-requisite to empowerment is transparency. At Increase, we commit to transparency by working in public. In practice, this looks like draft pull requests, work-in-progress documents, notes written and shared for every meeting, and emails sent to lists. There’s no opaque-box’ing from any function (except, of course, for personally sensitive information). This ensures that everyone (including future employees!) has access to the information that went into a decision.

Transparency requires clear communication. We operate in at least two complex domains: technology and financial services. Both have their own jargon and acronyms. Whenever possible, we rely on primary sources and avoid shorthand communications that can act as a barrier to information, question asking, and understanding. (In other words: expand acronyms!)

“The central tenet of our culture is empowerment. It drives the way we make decisions, our access to knowledge, our ability to make changes, and our sense of urgency.”

Trust

Building trust with both our users and our partners is critical to growth. We maintain trust by keeping our promises, acting with honesty and integrity, and operating responsibly. Whenever we have an opportunity to go above and beyond to build trust, we should take it.

Empowerment also hinges on trusting others at Increase, and trusting they trust you. We’re still a small team, in the early innings of a long journey. We navigate it best by consistently being empathetic, humble, and kind.

Operating this way comes with overhead. For example, disagreeing with an owner’s decision but committing to it can feel uncomfortable. There’s often a temptation to carve out a sub-decision, show how two domains of ownership are contentious and therefore require consensus, or re-open a decision a short period later with a different owner. We’re certainly imperfect but we watch when we’re doing these.

We also watch out for read-access not equating to write access, drive-by comments⁰, costly casual curiosity, and psychological safety. If wide transparency becomes fundamentally at odds to psychological safety, we’ll choose psychological safety.

These tenets are not perfect or complete. We’ll add to them and revise them over time. If this way of working resonates, we’d love to hear from you.

Notes

https://www.recurse.com/social-rules ↩

2023 Q4 Newsletter

Sun, 31 Dec 2023 00:00:00 GMT

December 18, 2023

Wire Transfers now limit the beneficiary_name to 35 characters, the message_to_recipient to 140 characters, and each line of the beneficiary_address to 35 characters.

December 11, 2023

Check Deposit submissions now show the time a check was sent to Check21.
You can now set debtor_name and ultimate_debtor_name on Real Time Payments Creation .

December 04, 2023

You can now enroll accounts in IntraFi for higher FDIC coverage.
You can now create security incidents in the Dashboard.
You can now connect your Increase accounts anywhere Plaid is supported.

November 27, 2023

You can now receive and submit Proof of Authorization Requests in the API.
You can now submit platform complaint metrics via a CSV file.

November 20, 2023

You can now filter Transactions by description in the Dashboard.

November 13, 2023

We’ve added new Transfers , Account Numbers and External Accounts tabs in Dashboard for easier navigation.
You can now filter Entities, Account Numbers and Accounts by name in the Dashboard.
You can now filter External Accounts and Cards by description in the Dashboard.
You can now filter Transfers by date in the Dashboard.

November 6, 2023

You can now save beneficiary address and name details when creating new External Accounts in the External Accounts tab.

October 30, 2023

You can now download account verification letters from Dashboard. This is helpful if you need to demonstrate ownership to a third party.
You can now export a CSV of Entities.
You can now see which Entry Effective Date was used for an ACH Transfer.
You can now save beneficiary address and name details when creating new External Accounts in the Money Movement flow for reuse.

October 23, 2023

ACH addenda are now visible on the Inbound ACH Transfer object.
There is a new verification hash on the card authorization resource that shows the address provided by a customer, the address we match it against, and the result. It also shows the result of the CVC match.
We now expose a few more network identifiers on our various card payment-related resources, nested under network_identifiers.
We’ve added support for Automatic Fuel Dispenser payments, where the initial authorization will be followed by a card_fuel_confirmation that updates the amount to the actual fuel pump amount.
You can now filter the Transfers list in Dashboard.
ACH Transfer objects now include an effective_date that tells you which day a transfer was processed.
You can now search Inbound Wires by Input Message Accountability Data (IMAD) and Trace Number in the Dashboard.

October 16, 2023

We updated our Proof of Authorization flow to be more guided.
You can now see the Check Transfer ID on Check Transfer Deposits in the Transactions API.

October 9, 2023

You can now filter Transactions by amount in the Dashboard.
You can now view Fee Statements by Program in the Dashboard.
You can access more Federal Deposit Insurance Corporation (FDIC) coverage to protect your account balances above $250K. Reach out if you’d like to enroll in our Extended Deposit Insurance.
You can now see failed scheduled transfers in the dashboard and we will email you if they fail.
You can disable notification emails altogether in Settings .
There is now a direction field on Card Authorization resources that shows whether it’s a settlement or refund authorization.
We fixed a bug where Card increment amounts would sometimes have the wrong signage.

October 2, 2023

You can now search for ACH Transfers by Trace ID and for Wire Transfers by Input Message Accountability Data (IMAD) in the Dashboard.

How Ramp scaled a successful bill pay product with Increase

Tue, 28 Nov 2023 00:00:00 GMT

Ramp is the ultimate platform for modern finance teams. From spend management and expense management software, to bill payments and vendor management, Ramp’s all-in-one solution is designed to automate finance operations and build healthier businesses.

2023 Q3 Newsletter

Sat, 30 Sep 2023 00:00:00 GMT

September 25, 2023

You can now see maximum string lengths in our API Documentation.
You can now simulate advancing a physical card shipment in sandbox.
When depositing a check in the money movement flow you can now review check images before depositing.

September 18, 2023

The Inbound ACH Transfer object now includes the originator routing number information.
The Inbound Wire object now optionally includes the originator routing number information.
You can now cancel physical card submissions prior to shipping.
You can now assign a compliance role to users.

September 11, 2023

You can now simulate creating actionable Inbound ACH Transfers to your account in sandbox.

September 4, 2023

We’ve added polish to our mobile experience to make it easier to view timeline data.

August 28, 2023

You can now action on Inbound ACH Transfers using the new decline and return APIs.
You can create a notification of change for Inbound ACH Transfers.
We’ve added new guides for understanding ACH debit funds holds and Outbound ACH Transfers .

August 21, 2023

You can now view FedACH processing windows and FedACH file submission details on our status page.

August 14, 2023

ACH transfers report when they were acknowledged by FedACH in the acknowledgement details.

August 7, 2023

You can now add a new Beneficial Owner to an existing Corporation entity.
Beneficial Owners can have multiple prongs within one Corporation.
You can fetch an image of the mailed check sent by Increase for a Check Transfer.

July 31, 2023

You can now manage Card Profiles in Dashboard.
Wire Transfers now allow alphanumeric characters in account numbers.
There are improved Dashboard filters for Transactions and Cards.

July 24, 2023

You can now make a Check Transfer that you, rather than Increase, mail.
Level 2 and industry-specific data is available under card_settlement and card_refund sources in the purchase_details object.
Level 3 data, such as line item level itemization of purchases, is available under the new /card_purchase_supplements API.

July 10, 2023

You can now upload rear images for driver’s licenses and other identification documents.
You can now view all of your prior document submissions in Dashboard.
We’ve updated transaction descriptions in Dashboard to be more readable.
We’ve added additional polish to our move money flows, improving the ability to send money to saved External Accounts.

July 03, 2023

We’ve added newly designed move money flows in Dashboard to make it easier to pay saved External Accounts, created a review step to reduce commonly made errors, and introduced a few other experience improvements.
Open Fee Statements for the current month are now visible in Dashboard.
Document requests for late returns and proof of authorization requests are now visible in Dashboard.
The ACH notifications_of_change attribute now has all of its change_codes documented.

2023 Q2 Newsletter

Fri, 30 Jun 2023 00:00:00 GMT

June 26, 2023

We’ve added a new guide for understanding the differences between Transactions and Transfers in our documentation.

June 19, 2023

We’ve refactored our documentation and API reference to improve navigation and surface more information by default.

June 12, 2023

We’ve added support for a Go SDK .
Checks can now be stopped before they’re mailed.

June 05, 2023

You can now view the raw return code ( raw_return_reason_code) on a returned ACH Transfer including a brief description ( return_reason_code).
Dashboard now surfaces additional information in object lists including Transactions, Cards, Account Numbers, and Transfers lists.

May 29, 2023

You can now view the interest rate earned by an Account in the Accounts API .
Post Office Boxes are no longer accepted as valid Entity addresses, with the exception of Army Post Office (APO) and Fleet Post Office (FPO) addresses.

May 22, 2023

If you have more than one Program, you’ll now need to specify a program_id when creating a new Account .
You can now create Programs in Sandbox .

May 15, 2023

New Entity views in Dashboard let you review and edit your information and give you access to quick actions, all in one place.
With Programs, platforms can now report compliance data (such as metrics, complaints, and third-party risk reports) directly in Dashboard.

April 17, 2023

You can now view detailed timelines for transfers in Dashboard.
The new pending_reviewing status on a transfer indicates when a transfer is under review by Increase.
The ACH Transfer API now includes multiple notifications_of_change, if they are sent by the receiving bank.

April 10, 2023

You can now override webhook Event Subscriptions for Real-Time Decisions in the sandbox by specifying an event_subscription_id in the simulation . This is helpful when multiple developers are building in the same sandbox environment.
Our new Balance Lookups API enables you to see the available and current balance of your accounts. This will soon replace the balance attribute on Accounts .
Our new beta Exports API enables you to download your Increase data in batches. Check out the Exports documentation for more information.
You can now update your Entity’s address in Dashboard.

April 3, 2023

We’ve written new guides to common Networks, such as ACH, Check 21, and Fedwire. Let us know what networks you’d like us to write about next!
You can now simulate an Interest Payment to your Account.
Transfer templates are now deprecated in favor of External Accounts .

2023 Q1 Newsletter

Fri, 31 Mar 2023 00:00:00 GMT

March 27, 2023

We’ve introduced Programs to guide the compliance and commercial terms for Accounts. You can also view your Programs in Dashboard .
beneficiary_address_line1 is now a required field on outbound wires for transfers made through Blue Ridge Bank.
We’ve launched Java and Kotlin Software Development Kits .

March 13, 2023

We’ve launched Python and Node Software Development Kits ! We’d love for you to try them out and give us feedback as you build your integration. Go, Java, and Kotlin are coming soon. Let us know if there’s another language you’d like us to support.

March 06, 2023

You can now require everyone in your Team to set up two-factor authentication on your Team’s settings page .
You can also view events related to your Team’s security changes, such as password resets and two-factor authentication changes, on your Team’s settings page .

February 27, 2023

You can now create and revoke API keys in Dashboard.
You can now simulate returning check deposits using the Simulations API .
You can now access the accompanying message that is printed on a CheckTransfer ‘s letter.

February 20, 2023

You can now return inbound ACH Transfers with our new returns API .

February 13, 2023

We’ve made usability changes to Dashboard, including a refreshed Account page.

February 6, 2023

We have a new landing page!
We now include Visa specific fields in card authorization requests that can be used to differentiate between online and offline purchases.
You can now receive and respond to inbound wire drawdown requests through our API .

January 30, 2023

We now support notes on CheckTransfers that will be printed on the letter included with the check.
You can now schedule transfers with any interval in Dashboard.

January 23, 2023

You can now link External Accounts using Stripe’s Financial Connections through Dashboard.

January 16, 2023

We now have a status page !
You can now view images of deposited CheckTransfers in Dashboard and the CheckTransfer API .
You can now simulate depositing a CheckTransfer with our Simulations API .
beneficiary_name is now a required field on outbound wires .

January 9, 2023

An Account’s available balance, which represents the balance less any open Pending Transactions, is now available via the Account API .

January 3, 2023

You can now approve and require approval on specific transfers, rather than all or nothing, through our API.
The ACH Transfer API now includes the time the transfer was submitted to FedACH, as well as beneficiary information.
The Wire Transfer API now includes the time the transfer was submitted to Fedwire, as well as beneficiary information.
Simulations now include richer data for ACH Transfers , Wire Transfers , and Real-Time Payments .
You can now filter Transactions with specific source categories using the Transactions List API .

2022 Q4 Newsletter

Sat, 31 Dec 2022 00:00:00 GMT

December 12, 2022

Increase is now generally available and no longer requires an invite code to sign up! Start building today !
Our Real-Time Payments API, built directly on top of The Clearing House network, now supports sending Requests for Payment. Reach out if you’d like to try it out!
You can now specify a return address on outbound checks with our Check Transfers API .
Card settlement transactions now surface the presentment amount and currency.
Transaction CSV exports from Dashboard now include the transaction type.
The Real Time Decisions API now includes the Card Profile ID if it was set by the Real Time Decision.

December 5, 2022

You can now receive webhook events for Digital Wallet Tokens using the Events API .
You can now simulate refunding a card transaction using the Simulations API .
Templates are being deprecated in favor of External Accounts , which are now available in Dashboard. Existing Templates will continue to work as expected, but you won’t be able to create new ones.
Check Transfers now have a returned status to let you know if there was an issue with the receiver.

November 28, 2022

You can now simulate card disputes using the Simulations API .
You can now upload supplemental documents for your entity using the Entity API .
You can now retrieve digital wallet tokens that are created when a user adds their Card to Apple Pay or Google Pay using the Digital Wallet Tokens API .
We now include additional originator information, such as name and address, on outbound wires.

November 14, 2022

We have a new platform integration guide to help you get started when building your business with a compliance forward mindset!
You can now use SMS to verify a card when adding it to a digital wallet using our Cards API.
You can now check if a routing number supports ACH, wire, and Real Time Payment transfers using our Routing Number API .

October 31, 2022

Receiving inbound Real-Time Payments is now generally available.

October 24, 2022

You can now specify an Entity’s relationship to your group using the Entities API .
You can now create beneficial owners in the Entities API without a passport.

October 10, 2022

You can now add Increase cards to digital wallets such as Apple and Google Pay! If you’d like to do this for cards you issue to your users, we also support custom artwork and branding. Reach out if you’d like to use this.
Our updated Check Deposits API gives you access to details of a parsed check, such as the account number printed on the check.
Users can now be re-added to a Group.

October 3, 2022

Our new Real-Time Decisions API lets you take actions in real-time for events such as card authorizations.
Our new Wire Drawdown Requests API lets you request that someone else send you a wire transfer.
There’s a new Entities API that includes richer information about your legal entities.

2022 Q3 Newsletter

Fri, 30 Sep 2022 00:00:00 GMT

September 5, 2022

Check numbers are now available in Dashboard and the Check Transfers API .
You can now simulate inbound Real-Time Payments to your account. Reach out if you’d like to use Real-Time Payments in production.
Our new company creation flow improves onboarding and entity creation.

August 29, 2022

You can now filter transactions by direction and transaction type in Dashboard.

August 15, 2022

Our new External Accounts API lets you store external account details for reuse.
You can now redirect cashback and interest to a specific account. Reach out if you’d like to do this.

August 8, 2022

You can now specify the amount in card settlement simulations .

August 1, 2022

Our new Cards webhook, which enables you to make real time decisions in the authorization flow, is in private beta! Reach out if you’d like to try it out!
Cards now appear in search.

July 25, 2022

API logs are now viewable under Developers.

July 18, 2022

You can now validate routing numbers against our new Routing Number API .
Our new Real-Time Payments API, built directly on top of The Clearing House network, is in private beta. Reach out if you’d like to try it out!
Account Statements are now available in the API.
Entities now have their own tab under Settings.
Events are now viewable under Developers.

2022 Q2 Newsletter

Thu, 30 Jun 2022 00:00:00 GMT

June 20, 2022

You can download a PDF of wire routing details for an Account Number from Dashboard.
If you need to stop payment on a Check Transfer, you may now do so via the API.

June 6, 2022

Our new Cards API, built directly on top of the Visa network, is now in public beta. Try it out!

May 30, 2022

You can now deposit checks in the API and Dashboard.

May 23, 2022

You can now simulate certain types of activity, such as inbound ACH transfers, in the sandbox.
OAuth applications are now generally available - you can make applications to work with data for other Increase users.

May 16, 2022

Files (both sent by you to Increase, and generated by Increase for you) are now exposed in the API. You can listen to file.created webhooks to know when Increase generates certain Files (such as statement PDFs) for you.
There are no longer limits on Account Number or Card creation in the sandbox.

May 9, 2022

Webhooks now have more predictable payloads and work in the sandbox. There’s a guide on how they work here.
There’s now an OpenAPI schema for our API.
This changelog now exists!