It’s all linked: auth vs settlement, and when money actually moves

In the flow of funds article I said card programmes run on two clocks, and that the gap between them is where expensive mistakes happen.

This is that article.

Here’s the thing it comes down to. When your customer taps a card and the terminal says approved, no money has moved. Not from their account, not from yours, not from anywhere. What’s happened is a promise.

The money usually moves day(s) later, through a completely different process and sometimes for a completely different amount.

Almost every card programme mistake I’ve seen traces back to a team that hadn’t internalised that.

An authorisation is a promise

Let’s walk the two seconds.

Your customer taps. The merchant’s acquirer sends an authorisation request across the scheme network. It arrives at your processor, acting for your programme, and one question needs answering: do we approve this?

To answer it your processor checks if the card is valid and active, runs fraud and velocity rules, and either checks the balance themselves or asks you to confirm if there is sufficient to approve the transaction. Not the balance in some abstract sense, the available balance on your ledger, which is the posted balance minus anything already held.

Then it answers. Fast, because the schemes require it. If your systems are too slow or unreachable, the scheme can answer on your behalf using limits you set in advance, which is a thing worth knowing about before it happens rather than afterwards.

If approved, a hold is placed against the customer’s funds and their available balance drops.

That’s it. That’s the whole event. A hold, a promise, and a customer who now believes they’ve paid for their coffee. No money has left any account anywhere.

Clearing and settlement are where money moves

Later, usually at the end of the merchant’s day, the transaction is submitted for clearing. This is the merchant saying: that promise from earlier, I’d like to collect on it now, and here’s the actual amount.

Then settlement. The card scheme calculates the net positions between participants and the money genuinely moves between banks. For your programme that means the customer’s account needs to be debited, with the funds swept to a settlement or prefund account held by/at your BIN sponsor, for them to send the funds to the card scheme who ultimately settles with the merchant via the acquirer. This process typically occurs on the next business day, depending on your card scheme and programme setup.

Only at that point has anyone’s money actually moved.

So you have three separate moments: the promise, the collection, and the money. Founders build products as if there’s one moment. That’s the whole problem.

Both ways to get this wrong

Here’s the design question, and it’s genuinely the most important one in a card build. Which of your ledger events fire on authorisation, and which fire on settlement?

There are two ways to answer badly, and I’ve seen both.

Treat the auth as if it’s money. The programme sees an approved authorisation and moves real funds, out of safeguarding, on to somebody, on the strength of it. It feels fine because most authorisations do clear, for the amount you expected, a couple of days later.

Then you meet the ones that don’t. The auth that expires because the merchant never collected. The one that clears for a different amount than it authorised. The one that gets reversed an hour later. Now you’ve moved money for a transaction that didn’t happen, and you’re unwinding it while your reconciliation quietly becomes littered with minefields. I once watched a team spend weeks trying to fix reconciliation because nothing matched anymore. The code wasn’t wrong, the event model was.

Wait for settlement before touching the balance. The opposite mistake is worse. Customer taps, gets approved, and their available balance doesn’t change because your ledger only updates when settlement lands. So they tap again. And again. You’ve built a double spend, and you find out about it from your negative balances.

The correct shape is boring: the hold hits the available balance at auth, the posted balance moves at clearing, and real money movement follows settlement. Auth changes what the customer can spend. Settlement changes what the programme owes.

The cases that only exist in production

The above is fine until reality arrives. These are the ones that catch people, and every single one is a product decision hiding in an operational detail.

Auth amounts aren’t final amounts. Petrol pumps, hotels, car hire and restaurants all authorise an estimate and collect something else. Your customer sees a hold for one number and a charge for another, and if your product doesn’t explain that, your support inbox will.

Auths expire. If clearing never arrives, that hold has to be released, and different transaction types get different windows. Never expire them and you strand your customer’s money for no reason. Release too eagerly and clearing turns up afterwards against a balance that’s already been spent, at which point you’ve extended credit you never intended to offer.

Clearing can arrive with no auth at all. Offline transactions can appear on transit gates and aircraft, or a merchant force posting. The money still has to move, so now you have a debit against a customer who may have nothing left. Negative balances aren’t a bug in card programmes, they’re an inevitability, and the question is whether you’ve decided in advance how you handle them.

Refunds and chargebacks run their own timelines. A refund is a separate credit that settles on its own schedule, which is why a customer who was refunded on Monday is asking where their money is on Tuesday. Chargebacks reverse through the scheme, sometimes long after the fact, and they hit the programme rather than reaching back into a customer’s balance directly.

Fees don’t arrive when you think. Interchange lands with settlement, not at auth. Modelling revenue off approved authorisations will give you a number that looks right but isn’t.

This all lands back on your flow of funds

Two things follow from this that belong on the diagram, not in a runbook.

Settlement has to be funded, and funding it is a movement of money. Somebody has to make sure the settlement account can meet the net position when it falls due, which means funds moving into it, on a schedule, from somewhere. If that somewhere is your safeguarded client money, that’s a specific movement with specific permissions, and your sponsor needs to have seen it. Back to the rule from the flow of funds piece: if it isn’t on the diagram, it doesn’t happen.

And you now have three sources of truth to reconcile, not two. Your ledger, the scheme’s clearing and settlement reports, and the actual movement in the settlement account. Reconciling ledger to bank alone will look clean while quietly hiding a real problem in the middle.

The question worth asking your team

If you’re building a card programme, ask whoever owns the ledger this: which of our events fire on authorisation, and which fire on settlement?

You want an answer that distinguishes them clearly and knows why. Holds and available balance at auth. Posting at clearing. Real money movement at settlement.

If the answer treats those as broadly the same thing happening at broadly the same time, stop and fix it now. It’s a couple of weeks of design work at this stage. Later on it’s a reconciliation project, a set of customer complaints, and a conversation with your sponsor about why funds moved for transactions that never cleared.

Approved is not paid. Everything else follows from that.

One final point. If you’re building on a mature banking platform, many of these behaviours already exist because someone has solved these problems before. That doesn’t mean you can ignore them. It means you can spend your time designing the customer experience instead of debugging the event model.

At Integrated Finance, this event model already exists because it’s fundamental to how regulated card programmes operate. The value isn’t that we’ve invented it. It’s that you don’t have to invent it yourself.