Four-party model

A card payment looks like one event (you tap or swipe, the terminal beeps, you leave with your goods) but it is at least two separate events riding on a structure the industry calls the four-party model: the cardholder, the merchant, the issuer (the cardholder's bank, which issued the card and bears the credit/fraud risk on it), and the acquirer (the merchant's bank, which holds the merchant's account and collects the transaction on the merchant's behalf), with a fifth party, the card network (Visa, Mastercard, RuPay, and others), sitting between issuer and acquirer as the rule-setter and message router, notably not itself a bank: it holds no deposits, extends no credit, and is not a party to the interbank settlement, in a role structurally similar to SWIFT's in the cross-border section.

How does a card payment work, step by step?

Event 1: authorization, in real time. At the point of sale, the merchant's terminal sends the transaction details through the acquirer to the network, which routes it to the issuer; the issuer checks the cardholder's available credit or balance and fraud signals and returns an approval or decline, typically within a couple of seconds. Nothing has settled yet, this is a message, a promise, a hold, and it is precisely why a merchant can see "approved" instantly while actually receiving the money only later.

Event 2, clearing and settlement, typically one to two business days later. The network aggregates the day's authorized transactions, calculates what each issuer owes each acquirer, and the actual interbank movement of funds occurs. Here is where the balance sheets genuinely move, and where a card payment's two forms diverge sharply. A credit-card swipe is a fresh loan origination at the point of sale: the issuer's balance sheet expands, a new receivable asset (the cardholder now owes the issuer) appears, matched by a new payable liability into the settlement chain toward the acquirer/merchant, which is exactly M7.01's "loans create deposits" mechanism reappearing at checkout, just with the loan denominated as a revolving credit-card balance rather than a term loan. A debit-card swipe, by contrast, is not a new loan at all: the cardholder's existing deposit asset simply falls, the same mechanic as an RTGS debit, the issuer's balance sheet does not expand, it merely reshuffles, because no new credit was created.

What is the merchant discount rate?

The merchant never receives the full ticket price. Three deductions, together called the Merchant Discount Rate (MDR), are taken out before the acquirer credits the merchant: the interchange fee (the largest piece, flowing from the acquirer to the issuer, compensating the issuer for the credit and fraud risk it carries, and, critically, set by the network, not negotiated between the two banks), the scheme/assessment fee (paid by the acquirer to the network itself, for running the rails and rules), and the acquirer's own margin (individually negotiated with the merchant). On a US credit card, interchange is broadly ad valorem (a percentage of the ticket) and, unlike debit, is not price-capped for most card types. Worked Example 6 computes a full MDR breakdown. US debit interchange, by contrast, is federally capped for large ("covered") issuers under Federal Reserve Regulation II, which implements the Durbin Amendment of the Dodd-Frank Act (2010): the capped fee is $0.21 plus 0.05% of the transaction value, plus a further $0.01 fraud-prevention adjustment for issuers that qualify for it, a fee that is mostly flat, not ad valorem, so its percentage of the ticket falls sharply as the ticket size rises (check the current cap figures at the Federal Reserve's own Regulation II documentation, like every fee in this module, Congress or the Fed can revise it). India's domestic equivalent scheme is RuPay, built and operated by NPCI on the same four-party structural logic, priced and governed under NPCI's own rules (check the current India interchange/MDR rules at npci.org.in and the RBI's card-payment circulars. India has, at various points, mandated zero-MDR regimes for specific transaction categories to promote digital adoption, another example of an operational fact set by regulatory circular rather than fixed economics).

How do you compute net settlement positions?

{
  "skill": "Generalizing a two-party (or few-party) netting/settlement calculation into a reusable, N-participant function",
  "use": "Have an AI assistant draft the scaffolding for a Python function that takes an N x N matrix of gross bilateral flows between banks (or CLS members) and returns each participant's net position and the system's overall netting efficiency, then verify the function's output against a hand-solved 2- or 3-bank case before trusting it on a larger matrix.",
  "tools": ["Chat assistants or a code-completion tool for the initial function scaffold", "A Python/notebook environment to actually run and test it, e.g. via numpy or pandas"],
  "prompt": "Write a Python function that takes an N x N numpy array of gross bilateral payment flows between N banks (row i, column j = amount bank i owes bank j) and returns: each bank's net position (inflows minus outflows), a check that all net positions sum to zero, the total gross flow, the total amount that must actually settle (the net funding requirement), and the netting efficiency as a percentage. Test it on a small, hand-computable 3-bank example first.",
  "verify": "Before trusting the function on real data, hand-verify it against a small case you have solved by hand (exactly the 3- and 4-bank matrices worked in this module) — confirm net positions sum to zero and the netting-efficiency percentage matches your own arithmetic. Never trust a settlement or netting script merely because it ran without an error; a silent sign error or a transposed matrix produces a plausible-looking, wrong answer every time (Guardrail 1-5, especially Recompute).",
  "diy": "You must already be able to compute a 3- or 4-party netting example correctly by hand (or step by step in a scratch script) before generalizing it — this module's worked examples and practice set are exactly that muscle. AI accelerates writing the generalized code; it cannot install the underlying arithmetic literacy.",
  "market": "US"
}

Modern Data Analysis note. Every netting computation in this module (UPI's multilateral settlement, a correspondent's bilateral netting, CLS's multi-member, multi-currency positions) is the same operation at heart: given a matrix of gross bilateral flows, each participant's net position is simply that matrix's row-sums minus its column-sums (money paid out minus money received), and the funding requirement is the sum of the negative (net-payer) positions. By hand, this is tedious past three or four participants; vectorized, it is one line: net = flows.sum(axis=0) - flows.sum(axis=1) over a numpy array or a pandas DataFrame, instantly correct for 4 banks or 4,000. This is not a toy analogy, it is close to what a real settlement engine (NPCI's for UPI, CLS's for FX) computes every cycle, just at far greater scale and with additional collateral and risk-management logic layered on top. The quant-code galaxy's DA branch is where you would actually build, test, and scale a settlement-netting engine properly; the discipline this module insists on carrying into that code is the one Worked Examples 5, 7, and 8 exist to install: never trust a netting script's output merely because it ran, verify it against a hand-solved case (confirm the net positions sum to zero; confirm the netting-efficiency percentage against your own arithmetic) before trusting it on a real settlement file.