This is part of the Toronto visit series.

“Do you have change for $5?”
“I can only give you one loonie and two lizes”
“What?”
Dumps coins on counter.
“Oh…”

(Canada has no bills under $5 and circulates the $1 and $2 coins.)

Before playing with Canadian money, I had thought that a $2 denomination, whether coin or bill, would be a great idea. But the problem I encountered here was that I was just unable to get very many $1 coins when the $2 coin was also widely circulating. This makes sense, because each transaction at most ends up giving you one additional $1 coin if done optimally. But if you had to always pay odd dollar-amount fees like the $3 streetcar fares, then you need many $1 coins which you don’t have. Compare this to the US system, where you get lots of $1 bills from daily transactions — up to four $1 bills in a transaction ($0-$4 in change). It surprised me that the latter situation is more flexible, because I did not take into account the dynamic effects that repeated transactions have.

Perhaps the intellectual impetus behind a $2 denomination is based on the idea of binary denominations, namely $1, $2, $4, $8, etc., which seems intuitively “nice” for efficiency. It’s hard to think why this should be desired now, it just seemed obvious. Perhaps in such a system the fewest coins/bills need to be carried to ensure all transaction amounts within a range are possible. Or perhaps the fewest coins/bills change hands on average over transaction amounts distributed a certain way (exponentially decreasing frequency as amounts go up?). Yet this system may not work so well, because though it is great for one transaction, you always need a complete set to make it work for the next transactions. The more critical element is net wallet change.

In fact you want this wallet distribution to be, in some rough sense, stable. At worst it should be invariant, and at best, surplus producing. What I mean is illustrated by this:

transaction amount: wallet change
$1: -1 $1
$2: +3 $1, -1 $5
$3: +2 $1, -1 $5
$4: +1 $1, -1 $5
$5: -1 $5

Why pay with $5 for a $2 fee rather than two $1? Well, we assumed that both payment and change-making use the “lazy algorithm” seen in real life: it’s the choice requiring the fewest coins/bills (and among those, the lowest denomination ones). Note that there is an asymmetry since the payer doesn’t have to make exact change but the cashier must settle with exact change.

If all transactions were integer amounts between $1 and $5, and we have an endless supply of $5 (let’s say that’s what the ATM gives), then some transaction amount distribution would make the wallet distribution invariant (as far as it concerns denominations under $5). For example, this (*):

transaction amount: frequency
$1: 17
$2: 3
$3: 3
$4: 2
$5: 1

On the other hand, a flat distribution would give a net surplus of +1 $1 per transaction. Either case would be fine. But in Canada with the $2 coin, the tabulation is different:

transaction amount: wallet change
$1: -1 $1
$2: -1 $2
$3: +1 $2, -1 $5
$4: +1 $1, -1 $5
$5: -1 $5

With the same transaction amount distribution as (*), we would end up with -3 $1 per transaction, a severe deficit. And unlike any other denomination, $1 is a necessity (it’s an atom). I’m not saying this transaction amount distribution is right, but whatever it be, the existence of $2 totally changes the wallet situation and in this case made things worse.

In the US, the existing denominations are kind of close to binary, except there is a magnitude gap between $1 and $5 ($2 bills do exist but rarely circulate), which seemed like a fault. But considering what happened in Canada, maybe this is a blessing in disguise.

Credit card number, name, billing address, expiration date are informational, so I don’t know how they have come to be used as “secrets” for a secure transaction. Seems like a terrible idea. Then there is the 3-digit CVV code. Would somebody mind explaining its utility to me? How does 3 more digits prevent fraud? (They are on the card just like the front-side numbers and they also must be disclosed during a transaction.)

There exists technology, but little infrastructure, for authenticating and trusting the remote host (or person — phone orders are even worse). For online transactions, banks have come up with at least two augmentations to the standard procedure to try to plug the hole. One involves password verification directly with the bank’s web site. Another is to issue single-use credit card numbers. Four soundbites ensue: Inelegant! Ad hoc! Not standardized! Unsatisfactory!

But this is moving in the right direction.

Many are grossly concerned with computer security and wireless channel security. Some are paranoid to the degree that nothing short of provably secure is acceptable for transmitting a few worthless bits that in reality nobody cares about. But we seem to settle for the foundational insecurity that underlies any kind of current remote payment using credit cards. Apparently managed insecurity is accepted, even if it deals with money, about which people should actually care. That’s a strange social phenomenon.