How Bank Transactions Actually Work

From a customer's point of view, a bank transaction looks instant. You tap a card in Athens, the terminal beeps, and your phone shows a spending notification before you put the wallet back in your pocket. The illusion is that money moved in that exact moment from your account to the merchant's account and the bank updated one balance field accordingly.

That is not what happened.

What actually happened is usually a layered workflow involving authorisation, holds, message routing, posting, clearing, settlement, exception handling, and sometimes later reversals or chargebacks. The visible transaction on the customer statement may be only one projection of a much larger operational process. A bank transaction is less like changing a number and more like moving a workflow item through several states while preserving accounting correctness and legal traceability.

This article explains that lifecycle in depth. We will cover card authorisation, available vs ledger balance, posting rules, settlement files, cut-off windows, holds, reversals, chargebacks, and transaction retries. We will also connect the banking-side transaction life cycle to core ledger design, because a bank cannot process millions of transactions a day if it treats each one as a single synchronous database update.

A Transaction Is a Lifecycle, Not a Moment

The word "transaction" is overloaded.

To a customer, it often means one visible item on a statement.

To a core banking system, it may mean:

• an incoming request from a channel
• an authorisation decision
• a hold placement
• one or more postings
• an external settlement obligation
• a future reversal or exception event

These are related, but not identical.

Consider a debit card purchase for €84 at a supermarket in Vienna. The lifecycle may look like:

1. POS sends authorisation request
2. issuer checks funds, status, fraud signals, card rules
3. issuer approves and places a hold
4. customer sees pending transaction
5. merchant later submits clearing record
6. issuer converts or matches hold into posted transaction
7. network and settlement processes move money between institutions
8. merchant receives funding through acquirer settlement

At step 3 no final interbank settlement has happened. At step 4 the customer often assumes it has. The banking system has to keep those distinctions straight because mistakes create support incidents, reconciliation breaks, and sometimes financial loss.

Authorisation Answers "May This Happen Right Now?"

Authorisation is the first critical stage for many transaction types, especially card payments and ATM withdrawals.

The question at this point is not "has this transaction been finally accounted for?" It is "should we allow it right now?"

The issuer or its processor typically evaluates:

• card status
• account status
• available balance or limit
• overdraft availability
• spending controls
• fraud signals
• velocity counters
• merchant category restrictions
• regional rules, such as whether the customer allowed cash withdrawals abroad

If the transaction is approved, the issuer usually returns an approval code and places a hold for the amount or the expected amount.

This is a decision stage under a tight latency budget. A POS terminal cannot wait thirty seconds while the bank runs end-of-day logic. The authorisation stack is therefore designed for fast checks against balances, holds, limits, and rules, often through specialised issuer-processing components rather than direct heavy synchronous interaction with every downstream accounting process.

That distinction explains why some authorisations succeed even though final posting later fails or changes form. Authorisation is permission under present information, not final accounting closure.

Holds Reserve Spending Power Without Final Posting

When a card transaction is authorised, the bank commonly places a hold or authorisation block on funds.

This means:

• the available balance decreases
• the ledger balance may remain unchanged
• the customer sees a pending item

Why use holds instead of posting immediately?

Because the authorised amount is not always final, and because the issuer may still be waiting for clearing data from the merchant side. Hotels, fuel stations, car rental companies, and some hospitality flows are classic examples:

• hotel check-in may pre-authorise €300
• actual check-out charge may later be €248
• fuel terminal may pre-authorise a round number before the final pump amount is known

If the issuer posted every authorisation as final accounting immediately, it would create unnecessary reversals and noise. Holds let the bank reserve capacity while waiting for the final settlement event.

This also explains available balance differences. If Elena has a ledger balance of €1,000 and two holds of €120 and €40, the bank may show:

• ledger balance: €1,000
• available balance: €840

That is not inconsistency. It is the bank distinguishing posted liabilities from reserved spending power.

Posting Answers "What Is the Official Accounting Entry?"

Posting is where the transaction becomes part of the account's accounting record.

For a final debit card transaction, a simplified internal posting may look like:

Debit: Customer current account               €84
Credit: Card settlement clearing account      €84

If a hold existed, the system may release or consume that hold as part of the posting workflow.

Posting is where the bank has to care about:

• debit and credit legs
• posting date
• value date
• event codes
• product rules
• duplicate detection
• references linking back to the external authorisation and clearing events

This is a slower and more accounting-sensitive stage than authorisation. The customer sees one statement line. Internally the bank may create:

• one customer-facing posted transaction
• one or more internal clearing entries
• journal records for reconciliation
• downstream general ledger feeds

Posting is the point where the bank starts saying "this transaction is now part of the account history" rather than "we have temporarily reserved capacity for it".

Settlement Happens Between Institutions, Not Only Inside the App

One of the biggest misunderstandings in payments is the assumption that authorisation and settlement are the same thing.

They are not.

In a four-party card model:

• customer holds a card from the issuer
• merchant uses an acquirer
• network routes messages between them
• settlement happens through scheme and banking settlement processes

When the issuer approves a customer purchase, the issuer has not yet transferred cash directly to the merchant. Instead:

1. merchant receives authorisation approval
2. merchant or acquirer later submits clearing
3. network computes obligations
4. settlement occurs between participants
5. merchant funding occurs through acquirer processes

The issuer core has to reflect these obligations correctly on its own books even before external cash settlement completes. That is why banks use settlement clearing accounts, suspense accounts, and reconciliation queues. The customer app may show a final posted debit long before the merchant's actual funding completes downstream.

For interbank transfers, similar separation exists. A transfer instruction may be accepted and posted internally while external rail settlement follows the timing of the scheme:

• same-day batch
• instant prefunded settlement
• correspondent chain movement

The customer experiences "sent". The institution manages posting plus rail settlement plus reconciliation.

Cut-Off Windows Still Shape Transaction Behaviour

Even in a world of instant UX, banking systems still care about time windows.

A transaction's economic behaviour can depend on:

• scheme cut-off time
• rail operating hours
• bank calendar
• currency calendar
• branch cut-off
• product-specific posting windows

Suppose Andreas enters an outgoing transfer in Frankfurt at 18:59, just before a scheme cut-off, and another at 19:01.

The bank may treat them differently:

• first transfer posts and value-dates today
• second transfer posts today but value-dates tomorrow
• or second transfer remains queued for next banking day processing

The customer may see both in the app tonight. The bank still has to know which one belongs to which settlement and interest period.

Cut-offs matter for:

• interest accrual
• delinquency calculations
• statement generation
• payment file inclusion
• liquidity management

This is why transaction systems care about both posting timestamp and value date. A transaction is not only an amount and a counterparty. It is also a timing event within the bank's processing calendar.

Reversals Undo Authorisations or Postings Explicitly

Real transaction systems fail, time out, or change. When that happens, banks do not simply "erase" the earlier event. They usually create an explicit reversal.

Common reversal scenarios include:

• ATM could not dispense cash after approval
• POS transaction approved but merchant aborted
• duplicate message detected after one item already posted
• network sent reversal advice
• manual correction needed

At the hold stage, reversal may simply release reserved funds. At the posted stage, reversal may require a compensating entry.

Example:

Original posted debit:      Debit customer €84 / Credit card clearing €84
Reversal entry:             Debit card clearing €84 / Credit customer €84

This explicitness matters because transaction history must stay explainable. If the bank later has to prove what happened during a dispute, it needs the chain:

• original authorisation
• posting
• reversal reason
• timestamps and references

Silent overwrites would destroy that evidence.

Chargebacks Are Not Normal Reversals

Customers often lump together refunds, reversals, and chargebacks. Operationally they are different.

Refund

A merchant-initiated credit back to the cardholder. Usually friendly and expected.

Reversal

An undo event for an earlier authorisation or posting, often due to system or processing conditions.

Chargeback

A formal dispute process where the issuer challenges the transaction under scheme rules because of fraud, non-receipt, processing error, or another defined reason code.

Chargebacks are operationally heavier because they involve:

• scheme reason codes
• evidence submission
• merchant/acquirer response windows
• representment and arbitration stages
• accounting treatment for provisional credits and later outcomes

From the customer's point of view a chargeback may begin with:

"I do not recognise this €219 transaction."

From the bank's point of view it can become a staged case workflow involving:

• temporary credit decision
• evidence collection
• acquirer interaction
• final win or loss accounting

That is why banks do not treat disputes as simple transaction edits. They are separate case and accounting processes linked to the original transaction.

Pending, Posted, and Settled Are Distinct States

A useful way to think about bank transactions is as a state machine.

For a card purchase, the states might include:

• received
• authorised
• held
• expired hold
• clearing received
• posted
• settled
• reversed
• disputed
• charged back

Not every transaction visits every state. But the bank needs a model rich enough to support them.

A simplified version:

POS auth request
    -> approve
        -> place hold
            -> receive clearing
                -> post transaction
                    -> settle interbank
                        -> final archived state
            -> hold expires if clearing never arrives
    -> decline
        -> no hold, no posting

This is the architecture behind many customer support observations:

• "It was pending yesterday and posted today"
• "The amount changed after the restaurant added the tip"
• "The petrol station hold disappeared"
• "The hotel pre-authorisation was released"

All of those make sense if you understand transaction state transitions.

Available Balance Differs from Ledger Balance Because Transactions Sit in Different States

This is the customer-visible consequence of the lifecycle model.

Suppose Maria starts with €1,200 ledger balance.

During the day:

1. card authorisation at bookshop €48, hold only
2. ATM withdrawal €100, posted
3. salary credit €2,000, posted
4. streaming subscription renewal €14, hold only

The balances may be:

Ledger balance    = 1200 - 100 + 2000 = €3,100
Available balance = 3100 - 48 - 14 = €3,038

If the customer sees both numbers without explanation, the bank looks buggy. If the system showed only one number, the bank would hide information the customer actually needs. The dual view is not a flaw. It is the visible reflection of transaction state.

The same logic extends to overdrafts and credit lines. Available balance may include:

• posted cash
• authorised overdraft headroom
• less pending holds
• less reserved funds for standing instructions

A customer can therefore have:

• negative ledger balance
• positive available balance because overdraft remains
• or positive ledger balance but lower available because holds consume spendable funds

The numbers are different because the economic questions are different.

High-Volume Banking Transaction Systems Care Deeply About Idempotency

Payment networks retry. Middleware retries. Mobile apps retry when users tap twice. Branch systems retry after terminal timeout. If the bank cannot tell whether an incoming message is genuinely new, it risks duplicate debits or duplicate credits.

So transaction systems assign identifiers and deduplication strategies such as:

• authorisation reference number
• retrieval reference number
• network trace id
• internal request id
• idempotency key from API gateway
• composite uniqueness rules by channel and event type

A robust issuer path may apply rules like:

if request_id already seen and status = approved:
    return prior result, do not post again
 
if clearing record matches existing posted transaction:
    ignore duplicate clearing
 
if reversal arrives for already reversed item:
    mark duplicate reversal, no new posting

This is one reason transaction systems feel conservative compared with ordinary SaaS applications. Retrying a web form twice may be annoying. Retrying a card debit twice is a serious production incident.

Banking Throughput Problems Are Usually Correctness Problems Wearing a Performance Mask

At scale, transaction systems do care about throughput. A large issuer may process huge peaks around:

• commuter hours
• payroll days
• shopping spikes
• holiday travel periods

But the hard part is not just handling more messages. It is doing so while preserving:

• per-account ordering
• hold and posting consistency
• duplicate suppression
• fraud rule latency
• settlement references

A high-volume transaction engine therefore often separates concerns:

• fast authorisation path
• posting and account engine
• clearing ingestion
• dispute and exception processing
• read-optimised customer views

That avoids forcing every card tap to wait behind every end-of-day task or every dispute workflow.

Still, the bank cannot split everything freely. Some events contend on the same account. If Nikos has €85 available and two terminals nearly simultaneously request:

• supermarket purchase €50
• fuel purchase €60

the system needs a strong enough ordering and hold-placement rule to avoid approving both if the product does not allow it.

That is why transaction scalability is inseparable from funds-control logic.

Transaction Systems Need Reconciliation Because External Parties Disagree

The issuer's internal view is not automatically identical to:

• card network files
• acquirer reports
• ATM journals
• payment rail confirmations
• merchant claims

So banks run reconciliation processes that compare:

• authorisation records
• clearing records
• postings
• settlement reports
• nostro movements

Breaks happen constantly:

• authorised but never cleared
• cleared for different amount
• posted but no external settlement match yet
• reversal received after hold expiry
• duplicate network message

Those breaks may route to:

• automated repair logic
• suspense accounts
• operations queues
• customer support workflows

This is another reason a transaction is not one row mutation. It is an object whose lifecycle spans several systems and several days.

Transaction Visibility in the App Is a Read Model, Not the Whole Engine

Mobile banking makes transactions look deceptively simple:

• icon
• merchant name
• amount
• pending or posted badge

Behind that clean screen, the bank may be assembling the view from:

• posted transaction ledger
• hold table
• merchant enrichment service
• card processor feed
• dispute case state

That means customer-facing transaction history is often a projection optimised for clarity, not a raw mirror of every underlying accounting and network event. Several internal events may compress into one user-visible line. Conversely one customer-visible dispute can expand into many internal records.

This is not deception. It is necessary abstraction. The bank still needs the deeper event trail underneath to reconcile, investigate fraud, defend disputes, and regenerate balances.

The Useful Mental Model

If you remember one idea from this article, use this one:

a bank transaction is a controlled progression through states of permission, reservation, accounting, and settlement.

The key layers are:

1. Authorisation decides whether the event may proceed now.
2. Hold placement reserves spending power where needed.
3. Posting creates official accounting entries.
4. Settlement resolves obligations across institutions or systems.
5. Reversal, refund, or dispute handles the non-happy path later if necessary.

That is why available balance differs from ledger balance. It is why a restaurant amount can change after tip adjustment. It is why a hotel hold can sit for days. It is why a chargeback is not the same thing as a refund. It is why banks obsess over cut-off times, duplicate suppression, and reconciliation.

The customer sees a line in the app. The bank sees a transaction lifecycle with accounting, risk, timing, and settlement consequences.

Appendix: A Direct-Debit Example Shows a Different Kind of Transaction Lifecycle

Card flows get most of the attention because they are visible and fast. Direct debits show that transaction lifecycles can be slower and more rule-heavy.

Suppose a gym in Barcelona collects a monthly direct debit of €39 from Sofia's account.

The flow may include:

1. mandate already exists
2. collection file submitted
3. bank validates account and scheme data
4. debit posts to customer account
5. settlement occurs through the scheme
6. customer may still have return rights under scheme rules for a period

This means the transaction can be:

• accepted and posted today
• economically challenged later through a return
• subject to different legal rights than a card purchase

So even though the customer sees one debit line, the bank still models:

• instruction
• posting
• settlement
• return window
• possible reversal or dispute route

The general principle holds. The transaction is a managed lifecycle, not a single atomic business moment.

What the Issuer Actually Receives During a Card Authorisation

The customer taps a card or phone at a terminal, but the issuing side does not receive a vague message saying "please move money". It usually receives a structured authorisation request containing enough information to make a narrow decision under time pressure.

Depending on the rail, processor, and card product, the issuer or issuer processor may see fields such as:

• primary account number or token
• expiry and card sequence data
• merchant identifier
• merchant category code
• terminal identifier
• acquirer identifier
• transaction amount and currency
• local transaction time
• point-of-sale entry mode
• e-commerce or card-present indicators
• recurring or instalment indicators
• stand-in or retry flags
• cash withdrawal, purchase, refund, or balance inquiry type

That message is then enriched by the issuer side with its own state:

• account status
• card status
• customer risk segment
• previous authorisation velocity
• available funds
• overdraft status
• country and merchant controls
• known fraud patterns

This matters because transaction processing is not just accounting. It is real-time decisioning on top of accounting state.

For example, a €42 restaurant purchase in Milan may be approved not only because the account has sufficient funds, but because:

• the card is active
• the terminal entry mode looks normal
• the merchant category is expected
• the amount is within a normal range for that customer
• the country is not blocked
• the previous ten-minute spend velocity is acceptable

If one of those conditions fails, the issuer may decline even with sufficient funds. So the transaction lifecycle begins with a risk and control decision, not with a debit entry.

This is also why banks often have distinct authorisation platforms and core posting platforms. The authorisation side must answer quickly and safely. The posting side must answer correctly and durably. Those goals overlap, but they are not identical.

Routing, Switches, and Processors Sit Between the Tap and the Bank Core

The customer imagines the terminal speaking to "the bank". In practice there are usually several systems in the path.

For a card transaction the path may be:

1. terminal
2. merchant payment gateway or acquirer host
3. card network switch
4. issuer processor
5. issuer decision engine
6. issuer core or balance service

In some banks the issuer processor and the core are tightly coupled. In others they are run by different vendors. In others the bank maintains a modern authorisation stack that talks to a legacy core over controlled interfaces. The customer does not see any of this, but transaction design is heavily shaped by it.

Every hop can add:

• latency
• retries
• duplicate risk
• field translation
• monitoring and timeout rules

Suppose a customer taps a phone on the metro in Lisbon. The acquirer may send an online authorisation request through a network switch. The issuer processor might consult a fast balance cache or balance service rather than asking the core to lock the account record synchronously for every field-level decision. If the decision comes back in a few hundred milliseconds, the terminal prints the receipt and the customer walks away.

What matters architecturally is that the message path is designed for speed and resilience, while the accounting path is designed for correctness and replayability. A transaction system that confuses these two goals either becomes slow enough to fail commercially or loose enough to fail financially.

A Single Purchase Can Produce Several Different Amounts

One of the most common support questions in retail banking is some variation of:

"Why did the transaction change from €70 pending to €83 posted?"

This usually happens because the transaction lifecycle allows the amount to evolve.

Typical cases include:

• restaurant bill plus tip
• hotel pre-authorisation then final bill
• fuel pre-authorisation then actual pump amount
• partial shipment and later capture in e-commerce
• currency conversion finalisation

The important distinction is between:

• authorisation amount
• clearing amount
• settlement amount

These may be the same, but not always.

Restaurant tip adjustment

At authorisation time, the terminal may request €70. Later the merchant submits €83 because a tip was added. The issuer then has to decide whether:

• the original hold can absorb the difference
• additional tolerance rules allow the higher amount
• an incremental authorisation is needed
• the item must be referred for exception handling

Hotel or car rental hold

At check-in, the issuer may approve €300. Final clearing later arrives for €248. The bank should release the unused €52 rather than keep the full hold in place.

E-commerce partial capture

An online shop may authorise €180 for an order, then ship only part of it and capture €110. The rest may expire, or another later capture may follow depending on merchant practice and network rules.

This means the transaction record is often less like:

amount = €X

and more like:

authorised_amount = €300
cleared_amount = €248
reversed_amount = €52
posted_amount = €248

If the bank does not model that distinction explicitly, customer balances, reconciliation, and dispute handling quickly become inconsistent.

Merchant Capture Is a Separate Operational Step

Authorisation gets the merchant permission to proceed. Capture is the merchant saying "I now want to collect this money for real."

In many systems, especially e-commerce and hospitality, capture is not automatic at the exact same moment as authorisation. The merchant may:

• capture immediately
• capture later the same day
• capture only when goods ship
• capture partially
• fail to capture at all

Why is this important for the issuing bank?

Because the issuer may be holding customer funds in expectation of a later merchant action that never happens. If capture never arrives, the hold should eventually expire. If partial capture arrives, the difference should be released. If multiple captures arrive against one authorisation, network rules and merchant setup determine whether that is legitimate or suspicious.

So from the issuer's point of view, a transaction is often a conversation with gaps in the middle:

1. merchant asks for permission
2. issuer reserves spending power
3. merchant later asks to collect
4. issuer posts and reconciles

Banks that process large card volumes therefore treat hold management as a serious discipline, not a cosmetic UI feature. A badly managed hold book creates:

• customer complaints about missing available funds
• stale reservations
• incorrect affordability decisions for later authorisations
• reconciliation breaks when clearing eventually arrives

Expiry of Holds Is a Real Operational Problem

Holds are temporary by design. They should not live forever.

If a merchant never submits clearing, the issuer must eventually release the reserved amount. The release logic depends on:

• card network rules
• merchant type
• transaction type
• issuer policy
• whether partial or late clearing is still plausible

This is harder than it looks.

If the bank releases holds too aggressively:

• later genuine clearing may arrive against apparently free funds
• customers may overspend relative to expected obligations
• operations teams get more exception work

If the bank releases holds too slowly:

• available balance stays artificially depressed
• customers call support
• the bank looks unreliable even though ledger accounting is technically unchanged

Consider a fuel terminal in Prague that pre-authorises €150. The actual fuel taken is only €58, but the final message is delayed. If the hold remains too long, the customer experiences a missing €92 of spendable funds. If the bank releases too early and final clearing comes later, the bank must absorb the exception safely.

This is why hold-expiry jobs, hold-matching logic, and late-presentment handling are central pieces of transaction operations. They are not edge decoration on the side of the main flow.

ATM Withdrawals Show Why Authorisation and Physical Reality Can Diverge

ATM transactions are a good way to understand why banks need explicit reversal logic.

A typical ATM cash withdrawal flow may be:

1. terminal asks for authorisation
2. issuer approves and reserves funds
3. ATM attempts to dispense cash
4. terminal records success or failure
5. network and issuer receive completion or reversal signals
6. posting is finalised or undone

The dangerous part is step 3. The authorisation decision may be logically correct while the machine fails physically.

Possible failure modes include:

• no notes dispensed because of cassette issue
• partial dispense
• power interruption
• cash dispensed but completion signal lost
• message timeout while the customer still receives cash

From the customer perspective, "the ATM took my money" is one event. From the bank's perspective, there are several possibilities:

• issuer approved and cash dispensed correctly
• issuer approved, no cash dispensed, reversal should follow
• issuer approved, cash dispensed, completion signal delayed
• issuer approved, ATM and issuer disagree on what happened

That disagreement is why ATM systems rely on:

• electronic journal records
• switch logs
• ATM settlement and cash balancing
• reversal advice messages
• operations investigation queues

If the bank simply posted every approved ATM authorisation immediately and assumed perfect machine execution, it would create incorrect debits during mechanical failures. If it refused to post until every machine confirmation was complete, customer experience and operational throughput would suffer. So the transaction engine has to model these intermediate states explicitly.

Instant Transfers Feel Simpler Than Cards, but Their Timing Rules Are Different

Card rails are one kind of transaction lifecycle. Account-to-account instant transfers are another.

For an instant payment between two banks, the customer often experiences:

• confirmation in seconds
• final posted debit immediately
• beneficiary visibility almost immediately

This looks simpler than the card world because there is usually no merchant capture stage and no long-lived hold. But the transaction still passes through distinct layers:

1. customer instruction accepted
2. bank validates beneficiary, limits, sanctions, fraud, and account state
3. bank sends payment over instant rail
4. rail confirms acceptance or rejection
5. sender debit and settlement entries are finalised
6. beneficiary bank credits recipient

In instant schemes, settlement is often much closer in time to customer confirmation than in cards. But even then the bank still has to manage:

• timeouts
• duplicate submissions
• beneficiary bank rejects
• liquidity in prefunded or settlement positions
• cut-off or maintenance windows for non-instant fallback rails

Suppose Dimitris sends €600 from Athens to Berlin. If the rail confirms, the sending bank may treat the debit as final almost immediately. If the rail times out, the bank cannot simply guess. It may have to place the transaction into an uncertain state:

• accepted by channel
• awaiting rail outcome
• confirmed sent
• rejected and funds restored

This is still a lifecycle. It is just a different lifecycle from the classic card hold-and-capture path.

Batch Transfers and Salary Runs Depend on Cut-Off and File Acceptance

Not every bank transaction is interactive.

Corporate salary runs, supplier payments, and batch transfers often work through file submission rather than single customer gestures. In those flows, the transaction lifecycle can include:

1. file uploaded
2. format and mandate validation
3. file accepted or rejected
4. individual payment items scheduled
5. posting date and value date assigned
6. settlement file inclusion
7. return or rejection reporting later

This means a customer or treasury user can see several different statuses:

• file received
• file validated
• payment pending
• payment sent
• payment settled
• payment returned

Again the key point is that the visible transaction item is not the same thing as the whole operational state. For a salary payment the core may already know:

• when the posting will occur
• which banking date applies
• which settlement cycle is targeted
• whether a liquidity check passed

That timing machinery matters enormously around payroll days, month-end supplier runs, and tax deadlines. The mobile-app age did not remove those constraints. It merely hid them better from ordinary users.

Foreign Currency Transactions Add Another Layer of Uncertainty

Card and transfer transactions become more complex when the purchase currency differs from the account currency.

Now the lifecycle may include:

• original transaction currency
• billing currency
• issuer account currency
• estimated exchange rate at authorisation
• final scheme or bank conversion at clearing

Suppose a customer with a euro account buys something priced in Danish kroner while travelling in Copenhagen. The issuer may reserve an estimated euro amount during authorisation, but the final posted euro amount may differ because:

• the final cleared foreign amount changed
• the scheme conversion rate changed
• issuer foreign exchange markup applied at posting
• dynamic currency conversion was used or refused

That is why customers sometimes see:

• pending amount €91
• posted amount €93.40

From the issuer's side this is not necessarily a bug. It is the difference between a provisional reservation and a final converted posting.

Banks need transaction systems that can preserve both views:

• original purchase amount and currency
• final billed amount and account-currency posting

Without that distinction, support teams cannot explain the difference and reconciliation against scheme reports becomes painful.

Why Some Transactions Post Before Settlement and Others Wait

One subtle design choice in transaction systems is the relationship between customer posting and external settlement certainty.

There are two broad patterns:

Post before full external settlement finality

This is common where customer experience requires quick clarity and the bank is willing to manage later exceptions operationally. Card purchases often look like this once clearing arrives. The customer statement shows a posted debit even though broader interbank net settlement may still complete later in the day or cycle.

Wait for stronger external confirmation

This is more common where the bank wants to reduce exception risk, or where the external rail outcome is the real determinant of whether the transaction economically happened.

The bank chooses based on:

• rail design
• product risk
• legal finality rules
• customer expectations
• operational tolerance for repair

There is no universal pattern. What matters is that the institution is explicit about which layer defines the customer-facing state and which layer defines treasury settlement finality.

This distinction also explains why operations and support sometimes use different language. Support may say "the transaction has posted". Treasury may still be reconciling the corresponding settlement obligation. Both can be true at once.

Reconciliation Is a Continuous Process, Not a Nightly Footnote

People often imagine reconciliation as a boring overnight report. In reality, transaction-heavy banks treat it as continuous control work.

A basic reconciliation loop may compare:

• authorisation approvals
• clearing items received
• posted transactions
• reversals
• scheme settlement positions
• correspondent cash movements
• merchant or ATM reports

Each mismatch type tells a different story.

Authorised but not cleared

Likely hold expiry candidate, though late presentment may still arrive.

Cleared but not authorised

Can happen under certain network or offline scenarios, and must be reviewed carefully.

Posted but no settlement match

May indicate timing lag, file ingestion issue, or reference mismatch.

Settlement movement with no corresponding internal item

More serious, because it may imply incomplete booking or broken mapping.

Banks therefore maintain not only customer transaction systems, but also large supporting processes for:

• exception categorisation
• break ageing
• manual repair workflows
• suspense-account clearance
• reporting to finance and operations

At high scale this is not secondary administration. It is part of the transaction machine itself.

Offline Acceptance and Stand-In Processing Complicate the Story Further

Not every acceptance decision is made by the issuing bank in real time.

In some situations:

• a terminal may approve offline within configured card limits
• a network may perform stand-in processing when the issuer is unreachable
• a merchant may use deferred-authorisation models

These scenarios exist because commerce cannot stop every time one issuer has a temporary outage or one terminal has poor connectivity.

But they create complications.

If a network approves in stand-in mode, the issuer may only learn fully after the fact. If a card approves offline within chip rules, the account may not have been checked online at the moment of purchase. Later clearing may then arrive against a balance that has changed materially since the customer tapped the card.

This means some transaction systems must handle the uncomfortable case:

• no live issuer decision happened
• but the transaction is still economically real and now needs to be posted

That is another reason balances and transaction states cannot be treated as naive synchronous updates. Real payment ecosystems include controlled asynchrony and delegated decision paths.

Fraud Controls Can Hold a Transaction After Authorisation

Authorisation is not the only control point.

Banks often run transaction monitoring both:

• in line, before approving
• after the event, once richer context exists

For example:

• a card transaction may be approved because it looks individually normal
• a later pattern across several transactions may suggest account takeover
• the bank may then block the card, decline later activity, and sometimes open a dispute path on earlier items

This produces another important truth: "approved" does not mean "safe forever". It means "approved under the information and controls available at decision time".

Transaction systems therefore preserve detailed metadata not just for accounting but for later investigation:

• terminal country
• merchant category
• token or PAN reference
• device and channel indicators
• authentication method
• timing relative to previous events

Without that operational trail, post-event fraud analysis becomes guesswork.

A Full End-to-End Example: One Card Purchase from Tap to Final State

Take a debit card purchase of €64 at a pharmacy in Amsterdam. Assume the account starts with:

• ledger balance €920
• available balance €920

Step 1: Authorisation request

The terminal sends a purchase request through the acquirer and network. The issuer sees:

• purchase amount €64
• merchant category for pharmacy
• card-present contactless entry mode
• transaction time and local country

Step 2: Decision

The issuer checks:

• card active
• account active
• enough available funds
• no velocity breach
• no strong fraud signal

The issuer approves.

Step 3: Hold placement

The bank places a €64 hold.

State now:

• ledger balance €920
• available balance €856
• customer app shows pending card item

Step 4: Customer perception

The customer believes the money is gone. Economically, spending power is reserved, but the official posted account history may still be unchanged.

Step 5: Merchant clearing

Later that day or the next, the merchant submits clearing for the same €64.

Step 6: Posting

The issuer posts:

Debit customer account                  €64
Credit card settlement clearing         €64

The hold is consumed or released as part of matching.

State now:

• ledger balance €856
• available balance €856
• pending item becomes posted item

Step 7: Scheme settlement

The network includes the transaction in settlement calculations between issuer and acquirer participants. Treasury and settlement systems handle the actual inter-institution obligations.

Step 8: Reconciliation

The issuer reconciles:

• approved authorisation
• received clearing
• posted debit
• settlement position

If all references align, the transaction becomes part of the bank's ordinary completed flow.

That customer saw one purchase. The bank executed a multi-stage control and accounting process to make that single line safe and explainable.

A Failure Example: Why a Reversal Exists

Now take a card purchase of €210 at an electronics shop in Brussels.

Step 1

Authorisation is approved and a hold is placed.

Step 2

The merchant terminal crashes before completion and later sends reversal advice.

Step 3

The issuer receives the reversal event and releases the hold.

The customer may experience:

• a pending debit appears
• later the pending item disappears
• available balance returns

No final posted debit was needed.

If the issuer had already posted prematurely, it would need a compensating credit later. That is why the system distinguishes hold-state reversals from posted-item reversals.

Now imagine a worse case:

• approval happened
• merchant later submits clearing anyway
• reversal had already been processed

The issuer then needs duplicate and conflict rules to decide whether the later clearing is valid, stale, or operationally suspicious. This is the kind of case that makes transaction systems hard in practice. The happy path is easy. The conflicting-message path is the real engineering challenge.

Customer Support Questions Are Usually State Translation Problems

Most transaction support issues are not about arithmetic. They are about state translation.

The customer asks:

• "Why is this pending?"
• "Why did the amount change?"
• "Why did the same merchant appear twice?"
• "Why was my refund not instant?"
• "Why is my card blocked if you approved the earlier payment?"

The bank has to translate internal lifecycle state into customer language.

That requires the support tooling to expose more than just the final statement line. Good operational tooling shows:

• original authorisation
• current hold state
• clearing received or not
• posted state
• reversal or refund linkage
• dispute status if any

If support sees only the same simplified line the customer sees, the institution cannot explain its own transaction engine. Mature banks therefore invest heavily in internal transaction-timeline tooling, not only customer-facing app polish.

Some Rails Are Single-Message and Others Are Dual-Message

Another useful distinction is whether the rail behaves more like a single-message system or a dual-message system.

In a dual-message model, authorisation and later clearing are separate. Classic card purchase flows often behave this way. The issuer first gives permission, then later receives the financial presentment that turns the event into final posted accounting.

In a single-message model, the instruction that asks for permission is much closer to the instruction that causes the financial posting. ATM cash withdrawals and some account-to-account payment flows can look more like this, although real implementations still contain completion, reversal, and exception messages.

Why does this distinction matter?

Because it shapes:

• whether long-lived holds are normal
• how much amount drift is expected
• how long a transaction can remain pending
• how customer explanations should be phrased

If a bank applies dual-message assumptions to a single-message rail, it may keep funds reserved longer than necessary. If it applies single-message assumptions to a dual-message card environment, it may post too early and generate avoidable reversals. Good transaction architecture starts by respecting the behavioural rules of the rail rather than forcing every payment type into the same lifecycle template.

Refunds Feel Slower Because They Are New Transactions, Not Time Travel

Customers often ask why a debit felt instant but the refund takes days.

That difference makes sense once you stop thinking of a refund as deleting the original purchase. A refund is normally a new credit transaction travelling through its own merchant, acquirer, network, issuer, posting, and reconciliation path.

The original debit may already have been:

• authorised
• cleared
• posted
• settled

The refund then begins a separate lifecycle:

1. merchant initiates refund
2. acquirer accepts it
3. network routes it
4. issuer receives and validates it
5. issuer posts customer credit
6. reconciliation and settlement follow

This is why the bank cannot always make the credit appear at the exact moment a merchant employee says "refund processed". The merchant has usually initiated a new payment event, not rewound the old one out of existence.

Returns and Recalls Keep Transaction State Alive After the Customer Thinks the Story Is Over

Direct debits, transfers, and some scheme payments also show that final-looking transactions can remain economically active for longer than the app suggests.

A direct debit may post today and still be returned later under scheme rules. A transfer may be sent and then become the subject of a recall request because of fraud or beneficiary error. A card chargeback can create provisional credit long after the original retail purchase looked complete.

So the true state model of a bank transaction often extends beyond:

• pending
• posted
• settled

and into:

• returned
• recalled
• disputed
• provisionally credited
• finally resolved

That long tail is why banks retain references, message traces, case links, and accounting lineage for far longer than the customer-facing screen implies. The visible payment item may look finished. Operationally, the institution still needs to know exactly how to unwind or defend it if the story reopens later.

The Smallest Honest Summary

When people say "a bank transaction happened", they often compress four different realities into one sentence:

• permission was granted
• funds were reserved
• accounting was posted
• settlement was completed

Sometimes those events occur close together. Sometimes they are separated by hours or days. Sometimes one happens and another never does. The engineering challenge is to preserve correctness across all of them without making the customer experience unusable.

That is why transaction systems are full of:

• holds
• cut-off logic
• posting groups
• reversals
• settlement accounts
• idempotency keys
• reconciliation queues
• dispute workflows

The transaction line in the app is the polite, simplified summary. The real transaction is the lifecycle behind it.

That is how bank transactions actually work.