Payment Aggregator: Who Holds the Money, and for How Long
A payment aggregator collects the payer's money for a set of businesses at once, keeps it while the amount due to each of them is worked out, and settles with each afterwards. A payment gateway moves the instruction along and never receives a rupee of the money. Setu Payments Limited, an invented payment system, carried 1,200 crore instructions in the stated year against Rs 3,60,000 crore of value, an average of Rs 300.00/-.
One separation carries every party and every step in a payment, and it is the one to keep if nothing else is. The instruction and the money are two different things. An instruction is a message that says money is to move. An instruction travels in seconds, passes through several hands, and is not itself money. The money moves afterwards, between banks, along a path the payer never sees and the business never watches.
Hold that separation, and every party in a payment chain becomes readable. Each of them is doing one of exactly two jobs. Either it is carrying the instruction, or it has taken the money into its own hands on the way through. Whichever of the two a party is doing settles the name it goes by, what it is permitted to do, and what a business loses on the day it stops. Any party in any payment chain can be sorted by one question: does the money ever sit with it?
A payment confirmation shows up on the screen. Pick an answer now, ahead of the explanation: at that precise moment, where has the money got to?
What has actually happened when the screen says the payment is done?
An instruction has cleared its checks and been accepted, and what stands at the end of that is a debt between two banks that nobody has settled yet. An unsettled debt between two banks is the whole of it. The money has not moved. Nothing has arrived anywhere. The screen reports the top lane of a two lane journey, and the bottom lane has not started.
Picture a stall outside a single office building. Between eight and eleven in the morning it takes two hundred payments, and the person running it hears two hundred confirmations. Not one of those two hundred is money in the account yet. The confirmations are the stall's evidence that two hundred instructions were accepted. The money that matches them arrives later, in a lump, from a party the stallholder has an agreement with, and on a timetable that stallholder did not set.
The instruction and the money are two different things, and the confirmation reports on the first of them only. This is not a technicality that goes away as arrangements get faster. Faster arrangements shorten the gap between the two lanes. Faster arrangements do not merge the lanes. The checks that make an instruction safe and the discharge that makes an obligation disappear are different events, and different parties answer for each.
What does a payment gateway do, and what does it never touch?
A payment gateway picks the payer's instruction up wherever it was entered, delivers it to the party that has to approve it, and brings the decision back. Carrying the instruction out and the decision back is the whole job. A gateway handles a message about money and does not handle money. At no point in a payment does a rupee sit with it, not for a day, not for an hour, not for a second.
Carrying a message sounds like a small job until something goes wrong with it. An instruction that never reaches the party who must approve it is a sale that did not happen. An answer that comes back late is a payer staring at a spinning screen and giving up. Carrying a message reliably, at volume, at the busiest hour of the busiest day, is real work with real consequences. A gateway never takes custody, not once and not for a moment, and that single absence is what makes it a gateway.
So here is the test to carry into any conversation about any party in any payment chain, and it is one question long. Does the money ever sit with this party? If the answer is no, whatever the party calls itself and whatever else it does, it is carrying an instruction.
What does a payment aggregator do that a gateway cannot?
A payment aggregator receives the payer's money. Not a copy of the instruction about the money, the money. An aggregator receives that money on behalf of many businesses at once. The word comes from exactly that: many businesses' takings arrive into one place and are then separated out again. The aggregator holds what has arrived while it works out how much belongs to each business, and it pays each business later.
Every other thing written about an aggregator falls out of that one fact. Because the money runs through it, what it has on hand at any moment belongs to other people. Because it has that money on hand, it is the party whose decision fixes the day each business is actually paid. And because a business's takings rest with it for a stretch of time, that business stands behind it in a way no message carrier could ever put it.
The everyday version is a market where ten stalls share one cashier at the gate. Every shopper pays the cashier, the cashier reconcilesMatching two records of the same events against each other, line by line, until they agree. Here it means matching what arrived against what each business was owed, before anybody is paid. the takings against what each stall sold, and each stall is paid out at the end of the day. The cashier is not a stall's supplier and is not its customer. The cashier is, for those few hours, the party holding its money.
A gateway carries an instruction; an aggregator takes custody. Both may sit between the same payer and the same business, both may look identical on a screen, and the difference between them is the whole of what a business needs to know about either.
A party that moves the instruction along never has a rupee of the payment in its hands. A different party collects payers' money for a set of businesses and settles up with each of them afterwards. Which name belongs to which?
What does the term payment service provider actually cover?
Payment service provider is the term readers get caught by, and the reason is worth being blunt about. Payment service provider is not the name of a job. The term is a broad description, wide enough to take in whichever party a business ends up signing with, whatever that party turns out to do. Such a party may be carrying instructions. It may be taking custody. Doing both is common, and so is doing one of the two and handing the other to somebody the business has never heard of.
None of that is deceptive. Wide descriptions exist because businesses want one agreement rather than four, and a party that arranges the whole of it for them is genuinely providing a service. The trouble starts only when a reader treats the description as if it settled something. It does not. Two parties can both be accurately described that way and stand in completely different relationships to a business's money.
Meeting that description, the thing worth establishing is not the label but which of the jobs sits behind it, and whose money moves through whose hands as a result. A term that covers several jobs at once is a term to ask a question about, not a term to accept. Asking that question is not scepticism about the party. The question is the same care a reader would take with a delivery agreement that said the goods would be handled, without saying by whom or where they would sit overnight.
A party describing itself as a payment service provider puts an agreement in front of a business. What should the business want to know about that description?
What are payment rails, and what separates one from another?
Underneath every instruction there has to be an arrangement that actually leaves one bank owing another less and gets a payee's bank to credit the payee. An arrangement of that kind is a payment rail. A payment rail is the bottom lane of the two lane journey drawn above, given a name.
Rails have names, and the names differ from country to country. The names are therefore the least useful thing to learn about a rail. The shapes do not differ. A rail encountered for the first time, in a country nobody in the room has worked in, is readable the moment three questions are asked about it.
First: are instructions gathered up and nettedAdding up the claims running each way between two parties and moving only the gap that is left. A hundred amounts in both directions can be finished off by one transfer of whatever the two sides do not cancel. before anything settles, or does each one settle on its own? Second: is the payee credited before the settlement between the banks, or only after it? Third: does the arrangement run at all hours, or in stated windows with a cut-offA time after which an instruction stops waiting for the current round and joins the next one instead. The times themselves are a setting somebody publishes, not a property of the idea. after which an instruction waits for the next batchA group of instructions gathered together and handled in one go rather than one at a time. The alternative is to treat each instruction entirely on its own.?
The three answers are the whole of what separates one rail from another, and every named rail is simply one combination of them. The values behind them, the hours, the intervals, the limits on what one instruction may carry, are set by the Reserve Bank of India, and they move. Knowing that the three questions exist is durable. Knowing this year's answer to one of them is not.
A payment rail turns up that nobody has explained. Which set of three questions would make it readable?
Whose money is it while it is on its way?
Readers are loosest here, so this block is going to be exact. An amount on its way is one the payer no longer has and the payee does not yet have. Through that stretch it belongs to somebody, and who that is has a definite answer.
A gateway can be ruled out at once. Nothing ever reached it. Where custody was taken, the amount rests with the party that took it, and resting there does not make it theirs. The amount came in already promised elsewhere. Such a party holds a total it has to break up and pass on to named businesses, and every one of those businesses is a creditor of it until that happens.
Turned around, that gives the sentence a business should keep. A business that has taken a payment and has not been credited does not hold cash. The business holds a claim on somebody, and the useful thing to know is on whom. A claim is not an alarming thing to hold. Holding one is the position of a customer who has paid a deposit and is waiting for a delivery: perfectly ordinary, and worth being clear about rather than vague about.
Knowing on whom the claim sits is what separates a wait from a loss, and it is settled by the agreement a business signed rather than by the screen it read. Where money on its way must sit, and what may be done with it while it is there, are set by the Reserve Bank of India, and appear as a named row in the table below.
Somebody's shop has taken a payment and nothing has landed in the account behind it. What is in the shop's hands right then?
How large is the average instruction, and how is it worked out?
Setu Payments Limited reports two figures for one stated year and no others. The system carried 1,200 crore instructions. Rs 3,60,000 crore of value moved on them. The count and the value are the whole of the record behind every number worked out below.
The value divided by the count: Rs 3,60,000 crore over 1,200 crore instructions. Crore appears above the line and below it, so it drops straight out, and the unit remaining is rupees for each instruction. The answer is Rs 300.00/-. The division also runs backwards, and a division that works in only one direction is a fact memorised rather than a check that can be used. Take 1,200 crore instructions at Rs 300.00/- each: they carry Rs 3,60,000 crore, exactly the value reported.
Both figures are for the stated year and neither is a rate. Reading either of them as a monthly, a daily or a per-second figure quietly multiplies or divides it by whatever the period happens to be. A count for a year and a value for the same year produce an average for that year, and carrying the period along with the figures is the difference between a number that can be used and a number that will be misquoted.
Now the honest part, and it is more useful than the arithmetic. Rs 300.00/- is a quotientThe result of dividing one number by another. A quotient is a property of the two numbers divided, and not a description of any single item inside either of them.. The quotient is a property of the system, not a description of anybody's payment. The record is a single count beside a single value and not one figure more. Nothing in it says what the instruction in the middle was, how far the range runs, or where either end of it sits. The same Rs 300.00/- average is produced by a great many similar payments, and also by a handful of enormous ones sitting among a great many tiny ones. The two systems behind those pictures are not remotely alike, and a count and a value cannot tell which of them is in view.
A payment system carried Rs 3,60,000 crore of value on 1,200 crore instructions in a year. What is the average instruction, and what does that figure describe?
Take two systems that moved identical value across a year, one at Rs 300.00/- for each instruction and the other at Rs 3,00,000/-. Predict before reading on: which of them has to drive the cost of every step it takes for each instruction down to almost nothing?
Why does the average instruction decide how the whole arrangement is built?
The size of the average instruction decides the shape of everything built on top of it. Anything a payment system does once for each instruction, a check, a record written, a query answered or a reversalUndoing a payment that has already gone through, so that the money returns to the payer. How one is asked for and how long anybody has to deal with it are settled separately. handled, has to be carried by Rs 300.00/- of value in one system and by Rs 3,00,000/- of value in another. The work is identical in size. The value that has to pay for the work differs by a factor of a thousand.
Take the everyday version first. A courier who delivers one parcel worth two hundred rupees and a courier who delivers one parcel worth two lakh do exactly the same amount of walking. All of that is small against what is in the second parcel, so the second courier can afford a signature, a photograph, a phone call and an insurance line. The first cannot afford any of it, and has to find a way to do the walking so cheaply that it disappears against two hundred rupees.
Where the average instruction is small, every step taken for each one has to be driven down until it is almost nothing; where the average is large, a great deal more can be spent on each step, and usually has to be. The size of the average is why payment arrangements that look like they are solving the same problem are built nothing alike, and why the count is worth returning to again and again.
Neither arrangement is better than the other. Without knowing what each one is for, the question has no answer. A courier who checks nothing would be reckless carrying two lakh, and a courier who telephones about every two hundred rupee parcel would never deliver anything. The shape follows the job.
Hold the value still and move the average instruction
One control, and it moves the average instruction only. The value carried stays at Rs 3,60,000 crore at every setting. The same money is cut into portions of different sizes, and the number of portions that results is what changes. The control starts exactly where Setu Payments Limited reported, at an average instruction of Rs 300.00/-.
Rs 300.00/- average instruction, and 1,200 crore instructions to carry the same value
This is exactly what Setu Payments Limited reported: an average instruction of Rs 300.00/-, Rs 3,60,000 crore of value carried in the stated year, and 1,200 crore instructions to carry it. Anything done once for each instruction was done 1,200 crore times.
Educational illustration. Two reported figures and nothing else. Every setting other than the starting one describes a system that carries the same value at a different average. Each of those settings is arithmetic rather than an observation, and no second system is reported anywhere in the record. No charge, timing, limit or condition of any kind is computed at any setting.
Why can two systems carry the same value and share nothing else?
Pin the value carried at Rs 3,60,000 crore and let the average instruction be the only thing that moves. Set it at Rs 300.00/- and 1,200 crore instructions are needed to shift that value. Set it at Rs 3,00,000/- and the identical value goes across on 1.2 crore instructions, a thousandth of the number.
A figure has turned up twice there, and it is better said out loud than left hanging. One thousand is the factor on the average and one thousand is the factor on the count, and neither of those is chance or a slip of the pen. Average multiplied by count is the value carried, so holding the value still locks the two figures together, and whatever ratio appears on one side is bound to be the ratio on the other.
Test it with a different pair. Put the second average at Rs 1,500/- instead. Rs 1,500/- is five times Rs 300.00/-, and carrying Rs 3,60,000 crore at Rs 1,500/- an instruction takes 240 crore instructions, exactly one fifth of 1,200 crore. Five on one side, five on the other, and nothing round about it. The identity is built into holding the product still.
One system's average instruction is 1,000 times the size of the other's, and its instruction count is 1,000 times smaller. Is running into that same figure twice a coincidence?
The failure: a headline value quoted without its instruction count
The failure is taking the value carried as a measure of how big a payment system is, and never once turning to the count beside it. Rs 3,60,000 crore is the figure that gets quoted. The value is the larger and the more impressive of the two, and it sounds like it settles how big something is.
Follow it through and watch what breaks. Two systems can carry exactly that value. One does it on 1,200 crore instructions at an average of Rs 300.00/-. The other does it on 1.2 crore instructions at an average of Rs 3,00,000/-. Everything the first system does once for each instruction, it does 1,000 times more often than the second, for exactly the same money moved. What each costs to run, what each has to stand up to on its busiest hour, what each has to check and record and answer for, and what actually breaks when either breaks, all follow from the count. None of it follows from the value.
Who makes this reading: anybody comparing payment arrangements on the figure that is easiest to find, and the easiest to find is almost always the value. What it costs: a conclusion about cost, capacity and fragility built on the wrong one of the two numbers, and delivered with confidence because the number itself was correct. The fix is a single habit and it fits on one line. Any time a payment figure is put forward, ask for its partner. On its own neither figure will hold up a conclusion.
How does a business owner actually use any of this?
The ten minutes worth spending before signing anything that takes payments
The exercise works the same for a stall that takes two hundred payments a morning and for a shop that takes twenty, and it runs to four questions in one direction. First, the party being signed with is asked which of the two jobs it is doing: does the money pass through its hands on the way to the business's account, or does it only carry the instruction? The question has a plain answer, and a party that will not give one has said something by refusing.
Second, if the answer is that the money passes through, the next question is who exactly is holding it and for how long, and the answer belongs in writing where it can be found again. Asking is not suspicion. The answer establishes on whom the business's claim sits, and that one fact turns an unexplained delay into a question with an address. Third comes whether any part of the job is handed to somebody else, because the party signed with may not be the party the money passes through.
Fourth, and this is the one people skip, what a confirmation means is worth learning. A confirmation is evidence that an instruction was accepted. A confirmation is not evidence that the business has been paid. A business that runs its day on confirmations will be certain of money it does not yet have, and the day that matters is the day something in the lower lane is slow. The four questions are the whole of the exercise, and the asking is what they are for.
Who sets the conditions every party in a payment chain works under?
Four things here are settled elsewhere. Whether a party may operate in a payment chain at all, what it must do with money belonging to other people, what anybody may charge and every floor and cap on it, and how long anybody has to answer when an instruction goes wrong. All four are set by the Reserve Bank of India, and all four move.
So each of them is set down as a row that carries its own label and holds no value at all. An empty row is neither laziness nor caution for the sake of it. A figure of this kind, once printed, turns from out of date into simply incorrect the moment it moves, and anybody who picked it up would walk into a real decision carrying a wrong number confidently. An empty row with a label on it leaves a question and somewhere to take it. A row filled in once and never revisited leaves something that will be acted on and ought not to be.
There is a second reason the rows are worth having even blank, and it is the more useful one. Knowing that a condition exists at all is most of what a reader needs. Somebody who knows that there are rules about where money on its way must sit will ask the right question of the party holding theirs, whatever this year's rules happen to say. Somebody who has never heard that such rules exist will not ask at all.
Four conditions named here, and where each one is set
| What is set | The value here | Who sets it |
|---|---|---|
| The conditions on which each party in a payment chain is allowed to operate at all | Not stated here | Reserve Bank of India at rbi.org.in |
| What a party holding money belonging to other people must do with it, and where that money sits | Not stated here | Reserve Bank of India at rbi.org.in |
| What any party in the chain may charge, and every floor and every cap on it | Not stated here | Reserve Bank of India at rbi.org.in |
| How long a party has to answer once an instruction has gone wrong | Not stated here | Reserve Bank of India at rbi.org.in |
The middle column is filled in at the address written into each row. Blank, the sheet still earns its place: it names which four questions exist and where each one is answered.
Last question, and it carries the habit worth leaving with. A payment system's value carried last year is quoted. What is the next thing to ask for?
Where the empty cells above get their values
| Conditions named, with their values set elsewhere | Who settles it | Site | Checked |
|---|---|---|---|
| The conditions on which each party in a payment chain is allowed to operate at all | Reserve Bank of India | rbi.org.in | 25 August 2026 |
| What a party holding money belonging to other people must do with it, and where that money sits | Reserve Bank of India | rbi.org.in | 25 August 2026 |
| What any party in the chain may charge, and every floor and every cap on it | Reserve Bank of India | rbi.org.in | 25 August 2026 |
| How long a party has to answer once an instruction has gone wrong | 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.
