MAC (Message Authentication Code)

A message authentication code, or MAC, is a short code sent along with a payment message. It lets the system at the far end check two things: that nobody changed the message on the way, and that it came from a sender who holds the right secret key. NIST calls a MAC a cryptographic checksum produced by a message authentication algorithm. The code sits next to the message rather than in place of it, so a MAC hides nothing. The data stays just as easy to read as it was before.

That point matters more in payments than it first looks. A card request carries an amount, a merchant reference, a currency code and an account number, and none of those fields are secret in the way a PIN is. What matters is that nobody changed the amount between the till and the bank. It also matters that the request came from a real device, not something dressed up as one. Codes like this have done that job in card and bank messaging for decades. They work quietly, in the background of a great many payments that cross from one network to the next.

How A MAC Is Made And Checked

The sender runs the message through a keyed formula and adds the result to the end. The other side holds the same key. It runs the same sum on the message it received, then compares its own answer with the one that arrived. If the two match, the message is treated as real. Change a single byte and the answer will not line up. The receiver then turns the message away rather than guess at what the sender meant. That is the whole point: a near miss counts as a miss.

Why Integrity And Origin Differ

Integrity means the content has not changed, while origin means it came from who it claims to. A plain checksum gives the first but not the second, since anyone can work out an unkeyed checksum after altering the data. A MAC folds a secret key into the sum, so it covers both at once. NIST puts it in those terms: a MAC can vouch for the source of a message and for its integrity, with nothing else bolted on. That is why it earns its place in a payment message.

MAC, Hashing And Encryption Compared

These three get mixed up all the time. One-way hashing makes a fixed-length digest with no key at all, so it can spot a change but says nothing about who sent the data. Payment data encryption is about secrecy: it makes data unreadable to anyone without the key. A MAC does neither job. It leaves the data in plain view and looks only at change and at sender.

Which Formulas Get Used Most

Two families do most of the work. HMAC, set out in FIPS 198-1, pairs a secret key with an approved hash function. CMAC, set out in NIST SP 800-38B, builds the same idea on a block cipher such as AES, which suits hardware where a cipher is already to hand. ISO sets out 6 more block cipher methods in a standard of its own, and leaves key handling outside the scope of that work.

Keys Are The Harder Half

The formula is not usually where things go wrong. Keys are, because a MAC is only as sound as the secret behind it. So payment systems tend to make, hold and swap those keys inside a hardware security module rather than in plain software. NIST also advises that a key used for HMAC should not be reused for other jobs, and that rule gets broken more often than it should. It is one of the first things a reviewer looks for.

What A Failed Check Means

A failed MAC check is a hard stop, not a warning. The system turns the message away rather than act on half-trusted orders, and the failure is logged so someone can look into it. In a card flow the merchant tends to see this as a technical decline, not a call made by the card issuer. So a run of MAC failures on one till usually points to a key that has fallen out of step, rather than to anything the cardholder did.

Where Else These Codes Turn Up

Bank messaging leaned on them long before cards became the bulk of the volume. Messages moving over networks such as swift have long carried check values. A bank at the other end could then satisfy itself that a payment order had not been changed on the way. The same logic now shows up in signed webhooks, in API request checks, and in file transfer checks across modern payment plumbing.

No Single Control Carries It All

NIST is careful on this point. A passed check gives good grounds to treat a message as real, but that comfort is not absolute: an attacker still has a small chance of guessing a valid value. So a MAC sits inside a stack, not above it. finera. makes much the same case in its look at security layers in modern payment stacks. Message checks, tokenisation, transport encryption and access control each cover a different way of failing. Lean hard on any one of them and gaps tend to open where the others were meant to help.