Card Network: The Rule Book Two Banks Never Wrote Together
A card network writes the rules under which a business can take a payment from a bank it has never dealt with, and it runs the arrangement those messages travel over. A card network holds none of the payer's money, lends none of it, and decides no single payment. The payer's bank decides that, and the money itself moves later, between banks.
Here is what makes a card payment hard to picture, and it is not the technology. A card payment is three separate events wearing one name. A message goes out asking the payer's bank whether this instruction may go ahead, and an answer comes back in seconds. A record of what actually happened is presented afterwards, and the amounts the two banks owe each other are worked out from it. Then, later again, money moves between those banks and the business is credited. Three events, at three different moments, and one word covering all of them.
One distinction underneath all of this is already settled. A message and a movement are not one object: something that says move money is not the money moving. The instruction itself is not one message either. The instruction is a question, then a record, then a discharge, and almost everything that is puzzling about a card payment lives in the gaps between those three.
A card payment goes through at a counter and the screen turns green. Before reading on, commit to an answer: which party just decided that it could?
What does a card network actually do, and what does it never do?
The two things a card network never does come first. A reader who has those straight has most of the rest already. A card network does not hold the payer's money. The payer's bank holds it, or extends the credit standing behind the card, and the balance a payer sees is a claim on that bank rather than a pile of notes sitting anywhere. A card network also does not decide whether any one payment goes ahead. The payer's bank makes that decision, instruction by instruction.
The work a card network does is narrower than most people imagine and more valuable than it sounds. A card network writes the rules that every party agrees to follow: what a message has to carry, what an answer means, what order the events run in, and what each party is entitled to expect from the others. Then it runs the arrangement those messages travel over. A message leaving a counter in one town reaches a bank in another and comes back. A card network sells a rule book and the plumbing that enforces it, and that is the whole of the product.
In household terms: a cricket league does not bat. The league writes the playing conditions, fixes the calendar and appoints the umpires, and it is precisely because it does none of the batting that two teams who have never met can play a match on a Sunday. Take the rule book away and nobody can agree what counts as out. The result is not a rougher match but no match at all.
Why does a card payment need a rule book at all?
The problem comes before the answer. A stall outside one office building wants to be paid by somebody whose bank sits in another city. The stall and that bank have never met, have no agreement with each other, and have no particular reason to trust each other. The stallholder cannot ring the bank and ask it to send money, and the bank cannot take the stallholder's word for what is owed. The stall and the bank are two strangers, and a payment between strangers has to be built out of something.
The obvious repair is the one that does not work. If every business signed an agreement with every bank whose customers might walk past, one agreement would be needed for each pairing. Five businesses and four banks means twenty separate agreements, each negotiated, each maintained, each argued over when something goes wrong. A sixth business adds four more. Bilateral agreementsAgreements made between two parties only, binding those two and nobody else. Each new party to be dealt with needs another one of its own. multiply with the product of the two sides. Nobody builds a payment arrangement that way.
A common rule book turns that multiplication into an addition. The stall agrees once, on its own side. The bank agrees once, on its side. Both agreements point at the same rule book, and the rule book is what lets them meet. Five plus four is nine, and adding a sixth business adds one. One agreement each against a common rule book replaces an agreement between every business and every bank, and that substitution is the entire reason a card network exists.
The same substitution is why the rule book has to be boring and fixed in advance. The rule book decides what happens when a message arrives incomplete, when an answer does not come back, when the amount presented differs from the amount asked about. Neither counterpartyThe other side of an arrangement, whoever they turn out to be. What it means to have one, and what standing between two of them achieves, is worked separately. gets to decide those things afterwards in its own favour. The fixed answer is exactly what makes the arrangement usable by parties who will never speak to each other.
A stall outside one office building takes a payment from a bank in another city that it has never dealt with. What makes that possible?
Which parties stand around one card payment, and what does each one do?
Five roles, and no more than five. The companies differ from country to country and even from arrangement to arrangement. The roles do not, so naming the five by what they do rather than by who they are is deliberate.
| The role | What it does in one card payment |
|---|---|
| The payer | Gives the instruction, at a counter or on a screen |
| The payer's bank | Issued the card, holds the money or extends the credit behind it, and decides whether this instruction may go ahead |
| The business | Wants to be paid for what it just handed over |
| The business's side | Presents the instruction on the business's behalf and is where the business is eventually paid from |
| The card network | Wrote the rules and carries the messages between the two sides |
Five roles, and any arrangement is these five roles shared out among however many companies a country happens to have. Because it places a party nobody has heard of, the sentence is worth more than a list of company names. When a card reader arrives from a business with an unfamiliar name, the question is which of the five roles that business is performing, and whether it is performing more than one. In some arrangements a single company signs the business up, carries the message and settles with it. One company, three roles at once. In others those three sit in three different companies. The roles are the durable thing.
Two of the five deserve a note. The payer's bank is doing more work than the others combined: it issued the card, it carries the balance or the credit limitThe ceiling a payer's bank sets on what may be borrowed on a card at any one time. How that ceiling is arrived at, and what a borrower pays on it, are worked separately., and it answers the question every single time. The business's side is doing the mirror job on the other end. Between the counter and that party there is usually a payment gatewayThe software that takes an instruction from a counter or a screen and puts it into the arrangement in the form the rules require. Where it sits and whose books it touches are worked separately. as well, and a gateway is software rather than a sixth role.
What has an authorisation actually decided?
Authorisation is the block that repays slow reading. A message travels from the business's side, through the arrangement, to the payer's bank. The message asks one question: may this instruction, for this amount, on this card, go ahead? The payer's bank checks whatever it needs to check and answers yes or no. The checks are its own business and nobody else's. The answer comes back in seconds and the screen turns green.
An answer is all that has happened. The business has an answer. The business does not have money, has not been credited, and nothing has left the payer's bank. An authorisation is an answer to a question, and an answer is not a payment. Alongside the answer, the payer's bank may have set the amount aside against the card, so the payer's available balanceWhat is left to spend after the amounts already reserved against an account are taken off. It is a different figure from the balance itself, and the two moving apart is normal. falls by that much even though nothing has been paid to anybody. Reserving is not paying.
The everyday version is the deposit at a tailor's shop. The work is agreed, the tailor writes down the amount, and both sides now know the size of the obligation. Nobody has been paid. If the customer walks back an hour later and cancels, no money has to be pulled back out of anybody's till. None of it went in. The green screen at a counter is the same class of event: it is the moment the obligation became certain, not the moment the money moved.
One consequence worth carrying: because the payer's bank answers, the payer's bank is the only party that knows why the answer was what it was. Neither the business, nor the party that signed the business up, nor the card network was consulted. Those three parties carried the question and carried the answer.
An authorisation comes back yes and the counter screen turns green. Where is the money standing at that instant?
What does clearing report that authorisation never asked?
Afterwards, and it is genuinely afterwards rather than immediately, a record of what actually happened is presented through the arrangement to the payer's bank. The record is not a question. The record is a statement: this is what took place, this is the amount, here is the instruction it belongs to. From all the records presented, the amounts the two banks owe each other are worked out.
Authorisation asks whether an instruction may go ahead, clearing reports what did happen, and the two need not carry the same number. The last clause is the whole reason the distinction is worth attention. If the two always matched, they could be collapsed into one and nothing would be lost. The two numbers do not always match, and the familiar case is a booking.
A hotel room is booked and an amount is authorised against the card, say Rs 3,000/- as an illustration with a number put in so the shape has something to be. The stay happens, one meal is not taken, and the amount actually presented afterwards is Rs 2,400/-. The gap of Rs 600/- was never a payment. The gap was an amount reserved by an authorisation and then released, and the release is why an amount can appear against a card, sit there for a while, and then quietly vanish without anything having gone wrong at all. The payer sees two different numbers because there were genuinely two different events.
Authorisation asks one thing and clearing reports another. Which way round is it?
When does the money actually move, and between whom?
Later again. The banks discharge what they owe each other, and the business's side is credited, and from there the business is paid. Notice who the money moves between: two banks. The payer is not in that transfer and neither is the business. The line on the payer's statement and the credit in the business's account are consequences of a movement that happened between two other parties entirely.
The answer arrives in seconds, the record arrives afterwards, and the money arrives after that. Say it in that order enough times and the confusing cases stop being confusing. Between the answer and the record there is an obligation and no money. Between the record and the movement there is a worked out amount and still no money. Only at the end does anything actually move, and by then the payer has usually forgotten the purchase.
When each of those happens is not a fact of nature. The timing is set partly by the rule book and partly by the Reserve Bank of India, and both of those change. A timing written out here would be wrong rather than merely old on the day it moved. The order is durable. The clock is not.
A refund is agreed on something bought last week. Does it erase the original payment where it first appeared, or arrive as something new?
What lives in the gaps between the three events?
Almost everything anybody has ever found strange about a card payment, and it is all one idea in four costumes. Gather them in one place and each stops being a curiosity.
An amount can be held and never presented. The authorisation happened, the record never followed, and the reserved amount is released after a while. An amount presented can differ from the amount held: Rs 3,000/- authorised against the hotel booking above and Rs 2,400/- presented afterwards. An instruction can be authorised and then reversed before anything is ever presented. The tidy ending: the question was asked, answered, and then withdrawn, and the second and third events never happened at all. And a refund is not the payment running backwards. A refund is a new instruction sent the other way. The new instruction travels its own three events on its own schedule, and turns up later as a separate line rather than erasing the line already there.
Every one of these is a consequence of the three events being separate, and a reader who has collapsed them into one cannot explain any of them. Explaining all four is the test of whether the separation has landed. When somebody says their money was taken and then given back and cannot see why both appear, the answer is not about anybody's competence: it is that they were shown a single line called a payment and were never told it was three events.
Who decides whether one card payment goes through?
The payer's bank. Not the business, not the party that signed the business up, not the payment aggregatorA party that collects money for many businesses at once and passes it on to each. Whose books the money passes through, and what that party may do while it holds it, are worked separately. behind the counter app, and not the card network. For somebody standing at a counter with a queue behind them, no sentence is more useful, and it is worth being exact about. The arrangement itself gives no signal at all about who decided.
A declined instruction is a decision made by the payer's bank, and the payer's bank is therefore the party holding the reason for it. Everybody else in the chain carried a message. The business saw a red screen at the same instant the payer did and knows precisely as much about why. The party that signed the business up knows the instruction was declined and no more. The card network carried the question one way and the answer the other, and the answer arrived already made.
Knowing where the reason sits is a route rather than a lesson. Care at the counter and a well-put question change nothing. The information required is held somewhere other than where the arrangement invites anybody to look, and knowing which party holds it is the whole of the fix. How long any party has to answer a question about an instruction is set by the Reserve Bank of India, and it moves.
An instruction is declined at a counter and nobody at the counter can say why. Which party holds the reason?
What does an average instruction of Rs 300.00/- do to an arrangement built on messages?
Now put a number against the machinery. Setu Payments Limited, an invented payments company, reports two figures for the stated year and nothing else at all: 1,200 crore instructions, carrying Rs 3,60,000 crore of value. Put the value over the count and work it: Rs 3,60,000 crore against 1,200 crore instructions comes out at Rs 300.00/- for the average instruction.
The status of that average bears care. The average is a quotient, a property of the whole arrangement, and not a description of anybody's payment. Two figures cannot say what a middle instruction looks like, whether most are small, or whether a handful of enormous ones sit among a great many tiny ones. The same Rs 300.00/- comes out of both of those pictures, and the two arrangements behind them are not remotely alike. The average does show one thing, and it is a great deal: what the arrangement has to be able to afford.
Because every single instruction sets off at least a question and an answer, and then a record presented afterwards, the message traffic tracks the count of instructions and is untouched by the value written on them. An instruction for Rs 30/- and an instruction for Rs 30,00,000/- cost the arrangement the same rounds of messages. The same round of messages sits on Rs 300.00/- of value here and would sit on Rs 3,00,000/- in an arrangement built for large payments, so an arrangement that sends messages about every instruction has to make each round almost free.
Work the anchor and the size of it lands. Hold the value carried still at Rs 3,60,000 crore and put the average instruction at Rs 3,00,000/- instead. Rs 3,60,000 crore divided by Rs 3,00,000/- is 1.2 crore, and the arrangement carries that many instructions. Set the two counts beside each other: 1,200 crore against 1.2 crore is 1,000 times as many instructions, and therefore roughly 1,000 times as many rounds of messages, for exactly the same money moved. One figure went up by 1,000 and the other came down by the same 1,000, and they move against each other like that for one reason only: the value carried was pinned in place while the average was changed. Every charge any party makes for this is set by the Reserve Bank of India, and it moves.
Hold the value still and move the average instruction
One control, and only one thing moves with it. The value carried stays at Rs 3,60,000 crore for the year, exactly as reported. Slide the average instruction and watch the count of instructions, and therefore the rounds of messages, move against it. The control opens at the reported average of Rs 300.00/-, and at that setting the panel reproduces the 1,200 crore instructions in the figures above.
Rs 300.00/- average instruction
At an average instruction of Rs 300.00/-, the same Rs 3,60,000 crore of value is carried by 1,200 crore instructions, which is the count the two reported figures give.
Educational illustration. Setu Payments Limited is an invented payments company. Two figures are reported, being 1,200 crore instructions and Rs 3,60,000 crore of value, and every other average on this control is a chosen setting rather than anything that happened. No charge, timing or limit appears at any setting: each of those is set by the Reserve Bank of India and moves. Counts are shown to two decimal places wherever the division does not come out even, and the sentence says about when that happens.
Two arrangements each move Rs 3,60,000 crore over a year, one averaging Rs 300.00/- an instruction and the other averaging Rs 3,00,000/-. Which one sends more rounds of messages, and by roughly what factor?
The failure: the screen names everybody except the party that decided
An instruction is declined at a counter. Look at what the payer can actually see. The screen carries the business's name and the card network's mark, and there is nothing on it at all that names the party that made the decision. So the question goes to the business, and then to the party that signed the business up. Neither can answer it, and neither ever could. Days go by, and they are days somebody is out of a payment they still need to make.
Who reads it that way: anybody. Nobody arrives at that question through inattention. The arrangement gives no signal whatever about which party decided, so reading the only names on display is the sensible thing to do with the information shown. The failure is in what the screen displays, not in the person reading it.
The cost is time, first of all. Then a repeated instruction, declined again for the same reason nobody has yet been in a position to ask about. Then a bill that goes in late. The repair is a route rather than a lesson: the decision to decline sits with the payer's bank, so the payer's bank is the party that holds the reason, and that is where the question belongs from the start. How long any party has to answer such a question is set by the Reserve Bank of India, and it moves.
How does anybody standing at a counter use this?
Four questions worth having ready, at a counter or on a screen
Each of these is a question rather than an instruction, and they work the same for a household buying vegetables, a small business taking payments on a borrowed card reader, or an analyst reading somebody's payment volumes for the first time. Each one is answerable from what is set out here.
First: which of the three events am I looking at? A green screen is an answer. A line on a statement that has settled is a movement. An amount that appeared as Rs 3,000/- and then changed to Rs 2,400/- was a hold and then a presentment. Each of the three events has a different party doing the work and a different thing to ask about, so naming the event first turns a mystery into an ordinary sequence.
Second: which party decided? For anything about an instruction going through or not, the answer is the payer's bank, every time. Third: which party holds the money right now, and which one is merely carrying messages? The card network is always in the second group. Fourth, and this is the one that saves the most time: what am I actually waiting for? If the answer is settlement, the record is already in and the two banks owe each other something they have not yet squared off. A payment gone missing is a very different state of affairs.
For somebody reading an arrangement's figures rather than standing at a counter, the same four questions turn into one: a count of instructions gives the message load, a value gives the money movement, and the two are almost independent of each other. An arrangement whose count is enormous and whose average is small is doing a fundamentally different job from one whose count is small and whose average is large, whatever the two of them report as a total.
Who sets the conditions a card network works under?
Four conditions circled earlier are set by the Reserve Bank of India, and they get revised. A value written out for any of them would be wrong rather than merely stale on the morning it changed. So each appears as a row carrying its own label, with the name and the address printed where the value would otherwise sit.
The row about charges is the one readers most want filled in, and it is exactly the one that would go wrong soonest. Naming who sets it outlasts naming what it was. Knowing that a ceiling exists, that it applies, and where it is published is a fact that holds good for years. Knowing what the number was last August is a fact with a short life and no warning label on it.
Four conditions named here, and where each one is set
| What is set | The value here | Who sets it |
|---|---|---|
| The conditions on which a card network may operate a payment system in this country | Not stated here | Reserve Bank of India at rbi.org.in |
| Where the record of a card instruction may be kept | Not stated here | Reserve Bank of India at rbi.org.in |
| What a card instruction has to carry before it may be authorised | Not stated here | Reserve Bank of India at rbi.org.in |
| What any party to a card instruction may charge, and every ceiling on it | Not stated here | Reserve Bank of India at rbi.org.in |
Copy these four rows down, look each one up at the address sitting inside it, and write the values in yourself. The rows outlast whatever goes in the middle, so the sheet works as a checklist while it is still blank.
Last one, and it is the thing to carry away. Name the three events inside one card payment, in the order they happen.
Where the empty rows above get their values
| The condition named here | Where the value is set | Site | Address last checked |
|---|---|---|---|
| The conditions on which a card network may operate a payment system in this country | Reserve Bank of India | rbi.org.in | 25 August 2026 |
| Where the record of a card instruction may be kept | Reserve Bank of India | rbi.org.in | 25 August 2026 |
| What a card instruction has to carry before it may be authorised | Reserve Bank of India | rbi.org.in | 25 August 2026 |
| What any party to a card instruction may charge, and every ceiling on it | Reserve Bank of India | rbi.org.in | 25 August 2026 |
Setu Payments Limited is invented.
Educational material. Not advice on any investment, tax, budget or market position.
