jamtronix

Blogs that are mostly about payment systems technology: 

• Andy Orrock | Payment Systems (topnotch stuff! - jonno)
• jPOS.org (by the primary developer of jPOS - the open source Java ISO8583 framework)
• Financial Cryptography Where the crypto rubber meets the Road of Finance...

Blogs that are mostly about the business of payment systems:

• Aneace's Blog - Ideas from around the world on how to re-invent the payment transaction as a privileged moment of contact, communication and exchange between customers, merchants and their banks
• Linkdump on Payments - in the Netherlands - Europe - the World...
• Bankwatch - Which banks understand the web lifestyle?
• AllPayNews - Making Sense of Payments

Coder blogs that sometimes talk about payment systems stuff:

• Rambling Comments - Len Holgate's thoughts on this and that... Mainly test driven software development in C++ on Windows platforms...

If you've got any other suggestions for this list, post a comment.

Posted by Jonno Downes at 01:29 PM | Permalink

Ever since I started posting about Australian Payment Systems, I've been getting lots of hits on the site from people searching for a list of BSB numbers.

This list can be purchased, but lots of people are searching for a free copy on the net and I'm not sure why.

If you have a deposit showing up on your bank statement and you can't work out who it's from,  try this site which lets you lookup the details for a given BSB)

If you're after the BSB of your own account, don't assume you can get the right one from looking up a list - you really need to check with your bank!

If you are building an application and you want to validate BSB's that people enter, then you don't just need the list now, you also need to keep up to date with changes to the list, so you really should go buy a subscription. On the other hand, if you don't mind annoying people by rejecting their BSBs if someone opens an account at a new branch, then there's a copy of the list (dated 22 Nov, 2002) on the go software download page (look for bank.exe)

And if you're just curious about what banks there are, this table might be what you're after:

Bank Number	Bank Code	Bank Name	BSB's
01	ANZ	ANZ Banking Group	1097
03	WBC	Westpac Banking Corporation	1434
06	CBA	Commonwealth Bank	1692
08	NAB	National Australia Bank	2151
09	RBA	Reserve Bank of Australia	7
10	BSA	Bank of South Australia	198
11	STG	St. George Bank	88
12	BQL	Bank of Queensland	120
14	PIB	Primary Industry Bank	1
15	T&C	Town & Country Bank	7
18	MBL	Macquarie Bank	20
19	ADV	Advance Bank (Now St George)	11
21	CMB	Chase Manhattan Bank	44
23	BAL	Bank of America	4
24	CTI	Citibank	11
26	BTA	Bankers Trust Australia	20
29	BOT	Bank of Tokyo - Mitsubishi (Australia)	2
30	BWA	BankWest	137
33	STG	St. George Bank	106
34	HBA	HSBC Bank Australia	38
35	BOC	Bank of China	2
36	IBJ	IBJ Australia Bank	2
40	CST	Colonial State Bank	535
41	DBA	Deutsche Bank AG	2
42	TBT	Trust Bank	30
45	OCB	Oversea-Chinese Banking Corporation	4
46	ADV	Advance Bank (Now St George)	14
48	MET	Suncorp-Metway	407
52	TBT	Trust Bank	122
55	BML	Bank Of Melbourne	157
57	ASL	Australian Settlements Limited	25
63	BAE	Bass & Equitable Building Society	1
63	BBL	Bendigo Bank	25
63	GBS	Greater Building Society Ltd	5
63	HBS	Heritage Building Society	999
64	AUB	Australian Unity Building Soc Ltd	1
64	IMB	Illawarra Mutual Building Soc Ltd	2
64	IOF	IOOF Building Society Ltd	1
64	MBS	Greater Building Society Ltd	1
64	MMB	Maitland Mutual Building Soc Ltd	1
64	MPB	Mackay Permanent Building Soc Ltd	1
65	BAY	Wide Bay Capricorn Building Society	53
65	PPB	Pioneer Permanent Building Soc Ltd	2
65	ROK	The Rock Building Society Limited	1
66	SUN	Suncorp	1
70	CUS	CreditLink	36
73	WBC	Westpac Banking Corporation	1232
76	CBA	Commonwealth Bank	1585
80	CRU	Credit Union Services Corporation (Cuscal)	234
90	APO	Australia Post	60
91	ARA	Arab Bank Australia	12
91	FNC	Bank One	11
91	MCB	Mizuho Corporate Bank	1
91	SSB	State Street Bank and Trust Company	1
92	ING	ING Bank (Australia) Limited	1
92	MID	HSBC Bank plc	4
92	UOB	United Overseas Bank	1
93	AMP	AMP Bank	9
93	ICB	International Commercial Bank of China	2
94	BCY	Bank of Cyprus	9
94	LBA	Laiki Bank	7
94	MEB	Members Equity Bank	2
94	TBB	Taiwan Business Bank	1

 

Posted by Jonno Downes at 10:34 PM | Permalink | Comments (1)

As I mentioned in my last post, there's been a lot of consolidation in the grocery markets, and the players in that consolidation - Coles Myer Limited (CML), Woolworths (WOW) and Metcash (IGA) - are starting to expand in to other market segments. I've recently come across ideal firm size theory, which suggests there are limits to that expansion, so in this post I want to look at some of the factors that encourage and constrain that growth.

Factors promoting consolidation

Branding & Advertising

People like to buy brands they know about. The way to get a brand message to stick in peoples heads is keep repeating it over and over and over again. So the more money a brand can spend on advertising, the more popular that brand will be.

Purchasing & Distribution

Any product that has high capital costs in production and distribution will show economies of scale. So the more of a particular good a single retailer buys from a wholesaler, the lower the price that retailer has to pay to get those goods on to their shelves. Bigger retailers can even cut out the middle man, buy straight from producers and develop their own private labels.

Systems

Not everyone can hire only above average employees. A good operating system (manuals, POS systems, training materials) can get consistent (although not brilliant) results with workers who are neither interested or intelligent (one POS developer told me "our target user is a 16 year old high school dropout telling her friend what happened last night on Neighbours "). A good system costs a lot of money to develop, but that cost can be amortised across all the stores applying that system.

problems with consolidation

The battle between large and small business is not totally one-sided - large companies are subject to diseconomies of scale. Smaller businesses have much lower management overheads and are able to respond much faster to new threats and opportunities that appear in the market. Smaller businesses are also less prone to conflicts of interest between owners, managers, and employees (the limit case here is self employed workers, where one person fills all three roles).

models of consolidation

Some markets consolidate through one or two retailers expanding by acquiring or undercutting their rivals. These retailers have the benefits of centralised branding, purchasing and systems, and the disadvantage of centralised ownership.

In markets for low value, fast moving goods, where there's a lot of competition and branding has a big influence on consumer behaviour, franchises can prosper. Franchises have the advantage of centralised branding, purchasing and systems, and also the advantage of decentralised ownership. The franchise model dominates in areas where branding is important and the startup cost for each outlet is low enough that anyone with a bit of industry experience and a house to mortgage can be their own boss. The canonical example here is the fast food industry.

In some markets one or more open platforms can take hold. These give smaller businesses (who have the advantage of decentralised ownership) some of the advantages of centralised systems, and are especially prominent in services markets, where purchasing & distribution is not relevant, and personal relationships are more important than brands. E.g. the SABRE network gives independent travel agents the ability to sell tickets on any airline. Since all market participants have equal access to that system, there is no pricing or operational advantage for large players. Note that this benefits suppliers even more than buyers - if there was no open platform, then there would be huge benefits in centralising ownership of travel agents, which would lead to the emergence of one or two giants dominating the market, these giants would then be able to exert pricing leverage over the airlines. It's not surprising then that SABRE was actually created by an airline. The real estate market can also be considered to have an 'open platform' since cheap newspaper advertising and websites like domain lets an independent agent advertise to the same number of potential buyers as any of their competition. Again, if these media weren't open to all, then the market would consolidate around the handful of giant firms that could fund the production and distribution of their own advertising, and then those firms would be able to extract much larger commissions from sellers.

conclusions

Not really sure what to make of all this just yet. Ben Barren asked what impact will technology have?  Somewhere in all this WOW vs CML froth & bubble there's an open platform waiting to get built, something that will keep the independents and franchises in the game once POS systems with supply chain integretion and the ability to sell financial products start to become competitive weapons. I'll ponder a bit longer and see if I can discern it's shape.

Posted by Jonno Downes at 11:46 PM | Permalink | Comments (3)

Over the last 20 years, there has been a huge consolidation in the Australian grocery retail market. Two giant retailers (Coles and Woolworths) have opened up massive networks of supermarkets all across Australia. The number of stores owned by these retailers gives them huge buying power, so they are  able to negotiate very low prices from suppliers. They have also built out very efficient distribution networks (i.e. warehouses that suppliers deliver goods to, and trucks to get goods from the warehouses to the individual stores). This further cuts their costs, allowing them to undercut rival stores.

In order to compete with the 2 giants (who each have about 35% of the total market of groceries), the remaining independent supermarkets have turned to a company called IGA Distribution (owned by Metcash). IGA runs a distribution network, supplying supermarkets that account for about 15% of the total market. This gives IGA sufficient buying power to negotiate with suppliers prices that are about as good as the majors, and they run an equally efficient distribution system.

But the IGA strategy is to not own or manage any of the IGA branded & supplied stores. So while IGA stores share a common procurement and distribution system, they are NOT integrated at the POS level in the way that Coles or Woolworths stores are.

Now the grocery market has reached a stable configuration, Coles and Woolworths are taking their systems and distribution networks beyond groceries and in to other markets, e.g. they both already own, or have strategic partnerships with, liqour and petrol retailers, and both have started to make forays into financial services (e.g. Coles Myer Credit Cards).

As well as increasing buying power, each new segment allows cross-promotional initiatives that increase the "gravitational pull" of the retailer as a whole. e.g. Fly Buys drives business to all CML brands, and I think if CML ever issued a Fly Buys branded Credit Card that combine both loyalty programs on to a single card, it would be a huge winner. But all these initiatives require the use of a common IT platform.

Nop doubt IGA would very much like to be able to form alliances with organisations in other segments, e.g. partner with a petrol supplier, or a financial services company, but their ability to create these kinds of deals will be substantially undermined by the lack of a universal POS system that new products can be built into.

As n example of how IGA is suffering from their lack of a standard POS platform, consider their response to the 'fuel discount' programs offered by both Coles and Woolworths. Both the Coles and the Woolworths programs work in the same way, if you spend $30 or more at a supermarket, the POS prints a coupon on your receipt that can be redeemed at a participating service station, for a 4c a litre discount. This program drives business to both participating supermarkets and service stations, and so the costs of the discount can be split between both the benefiting parties.

When these programs first came out, the were very popular with consumers, and the fact IGA did not have a similar program hit their sales in a big way. So they were forced to respond, but since there is no centrally controlled POS infrastructure, the only system they could implement is one where supermarkets give grocery shoppers a discount equivalent to 4c a litre if they present a receipt for fuel from any service station when buying $30 or more of goods. This means that the supermarket has to wear the full cost of the program, they can't split the cost with a service station in the way Coles and Woolworths can.

As the new products made possible by networked POS systems - stored value products like gift cards, or financial services like bill payments, or enhanced loyalty programs - become more and more competitive weapons for the majors, there will be a huge amount of market pressure to create a common POS infrastructure to give the independents the same benefits of networking and standardisation that the majors get. i.e. there will eventually be a POS network that parallels the IGA distribution network. I doubt this is something that IGA would want to build and run themselves, but it is probably something they would encourage and promote. But I think once such a network gets built, it will rapidly expand outside supermarkets, and the leading franchisors in any segment that the Coles or Woolworths duopoly expands into will feel the pressure to join a larger cross-promotional group (hence my prediction of a loyalty program that combines IGA and Harvey Norman, amongst others).

There's a few forms this POS network could take. It could require a complete new POS system. (i.e. including the till, scanner, inventory system etc), or it could be a souped up EFTPOS terminal (managed by e.g. MoneySwitch) or maybe even a seperate device (such as a DialTime or Touch terminal). Or maybe even a combination of all of the above, i.e. using a new standard that replaces AS2805 with something a lot more extensible and easy to work with, and allowed both financial transactions (e.g. charging a credit card), as well as non-financial messaging (such as passing details of shopping baskets back to a central loyalty program server that logs it for future data mining, and responds with any applicable discounts). 

Like any system where Metcalfe's Law applies, the hardest part will be the initial bootstrapping and concensus forming. Will be a good prize for whoever gets there first though.

Posted by Jonno Downes at 11:39 PM | Permalink | Comments (1) | TrackBacks (1)

I've been thinking and writing about australian payment systems for a while now, because I'm a geek, so I'm interested in systems, and I'm a father-to-be, so I'm interested in money. So yesterday, when Cameron Reilly suggested PayPal was a threat to the banks monopoly on financial services I had to disagree.

As I said on Cameron's blog, there's three components to a financial service:

• the brand - including advertising & marketing.
• customer service - whether it's at a shopfront (e.g. bank branch) or via a call centre or website, you need to have ways to allow your customers to do business with you, and help them when they have problems.
• backend infrastructure - the databases and comms links etc that store and carry transactions.

These are really 3 seperate businesses, but at the moment most major banks are in all 3 of them. But there are also lots of businesses that do only 1 of them. For example, there's lots of brokers that do the sales & marketing of home loans where the customer service and infrastructure is provided by a major bank.

PayPal (like the banks) also cover all 3 areas, although I doubt they could repurpose their current infrastucture very easily to handle e.g. home loans or credit cards. Also as soon as you get into products more complex than straight money transfers, your customer service requirements will go way up. You'll need branches where people can get help filling out application forms, and ATM's where people can take cash out. Basically you need to stop being a purely 'online' company and start owning real estate. And it is much much harder to build a network of physical outlets out from a website than it is to add a website to an existing distribution system.

So while PayPal might try to offer more services, I think they will just be rebranding products offered by other companies. So rather than competing with the branches and infrastructure of ANZ / NAB /CBA / Westpac, they'll be competing with other resellers like Virgin Money to onsell the banks' products.

But that doesn't mean the banks aren't about to get shaken up. They will, just not by PayPal. The real threat for the banks is from organisations that already have strong brands, and lots of physical distribution points and customer service staff. Once again, Coles Myer and Woolworths will be the ones to force an industry realignment. And it's happening already - today Woolworths announced they are rolling out their own ATM network. Coles Myer offer Credit Cards and Insurance.

The major retailers have a big advantage over the banks when it comes to running a payment processing system - because they own so many retail outlets, lots of the payments will be closed loop, meaning no interchange or merchant service fees. I.e. it will be cheaper for Coles Supermarkets to take payment on a Coler Myer issued MasterCard than a CBA issued MasterCard.

Also, these retailers are able to develop new stored value products that work across their distribution network. e.g. the Coles Myer Insurance Claim Card. I expect to see a lot more 'single purpose' stored value products as well, like Woolworths 'Essentials' Card. Since Woolworths control the retail outlets as well as the payment instrument, they can ensure that the cards are not used to buy booze or smokes. Compare that with the Visa Debit cards issued to hurricane Katrina survivors for emergency supplies - they were used for gambling, porn and tattoos

So here's my tips for the Australian financial services market 10 years from now:

• Both Coles & Woolworths will offer a single integrated Credit/Debit & Loyalty Card (i.e. instead of having separate credit cards and a FlyBuys card, you will just hand over your Coles Myer issued credit card)
• There will be a loose federation of independent 'tier 2' retailers combining to offer financial products (stored value cards & loyalty cards) usable across that network. That federation will probably include IGA & Harvey Norman.
• 50% of EFTPOS transactions will be on Credit/Debit/Stored Value cards issued by retailers
• 20% of car & home insurance will be sold by retailers
• 10% of home and car loans will be sold by retailers
• At least one of the retailer programs will allow customers to download their receipts electronically. e.g. Woolworths will offer a credit & loyalty card that's integrated with MYOB. (American Express are pretty close to this already)
• The infrastructure underpinning the above will be a mix of in-house and rebadged 3rd party products. Where 3rd parties are involved, it will be agile infrastructure companies like MoneySwitch that win the business.

In  short, I'm predicting that the banks will lose their retail banking business to the retail giants, and their wholesale ('backend') banking business to the infrastructure specialists. Maybe even one of them will be gone (through a merger, there's no way the RBA would let a major bank collapse).

Posted by Jonno Downes at 01:01 PM | Permalink | Comments (2) | TrackBacks (2)

in PayPal vs the banks, Cameron Reilly asks what's going to be the discontinuous innovation into the banking industry, with PayPal being a contender.

Personally, I'm not that convinced PayPal is such a big deal here in Oz - with BECS direct deposits Australians already have a pretty cheap and easy way to send and receive money . So PayPal may be a competitor to BECS, but I don't think it changes the game in the way that it does in countries without a low-cost bank-to-bank transfer system.

let's put this to the test - I just did an ebay search for leaf blowers. There were a total of 9 results. 6 of them accepted payment by direct deposit but not PayPal, 2 took direct deposit AND PayPal, 1 took neither, none took only PayPal. Compare this to the first 5 results from US sellers, ALL of them accepted PayPal, none of them wanted a direct deposit.

So let's say PayPal is NOT going to be as disruptive here as it is in the US. It will certainly compete with BECS, and force the banks to reduce costs and add features, but I doubt it will ever really be used much outside of ebay.

But I still think there is room for a big shake-up in payments. But where I see the room for innovation is in getting a closer integration between the payment system and financial record keeping for consumers and SMEs. It seems absurd that so much work is done pumping data out of POS systems into things like Loyalty Programs and stock control systems (that can then talk to supply chain management systems that talk to wholesaler's systems) and yet I still get handed a tiny little thermal printed receipt that I then have to type in to MYOB or Excel or whatever.

I know there's some niche products like fuel cards, which use custom (retailer specific) extensions to EFTPOS transactions to include lots of details about the goods and services being paid for.That way the fuel card issuer can send you a single monthly statement (or even make it available for electronic download) that has all the data you need for your financial records for vehicle expenses.

This works great for expenses related to company cars (which is certainly a huge market) but unfortunately there's not yet a more general solution here. I guess there's a few ways this could happen. Maybe AS2805 could be extended so each EFTPOS transaction includes the full shopping basket being paid for (including GST on each item), and then my bank website  could let me download the data or even better, let me assign some kind of expense category to each line item, and maybe even do some of my BAS calculations for me (assuming I tell the bank my ABN, and that the card is being used to run a business, so all GST I pay with that card is claimable). That's a pretty huge migration though (i.e. upgrading every single EFTPOS terminal  and every POS system in OZ), can't see that happening any time soon.

Or maybe as POS systems get smarter and broadband becomes ubiqutious, there might be room for some kind of multi-retailer loyalty program where the benefits for the consumer include electronic access to the transactional data that is collected in some industry standard format like OFX.

Or... maybe I'll just stfu and keep collecting those crappy thermal paper receipts and typing them in to Excel every time my wallet gets so full of the damn things that I can't sit down anymore.

Posted by Jonno Downes at 04:49 PM | Permalink | TrackBacks (1)

A couple of weeks ago, I posted about the non-bill that Telstra sends me every month. At the time, I assumed the reason for the $0.56 charge existing at all was that I had underpaid the final bill.

But the same thing has just started happening to Angela, who is now getting a $0.09 non-bill sent to her after also cancelling a service. And a closer inspection of the first non-bill shows that Telstra have charged a 9 cent fee for paying the previous bill by credit card.

This is actually the result of the RBA rulings that now allow merchants to explicitly pass on merchant service fees (and thus stop retailers having to raise prices for everybody to subsidise credit card loyalty programs). If you look at the fine print on the back of a Telstra bill, you'll see that paying by credit card incurs a small percentage fee, with different fees being charged depending on what credit card is used).

This fee can obviously only be calculated and charged after each bill has been paid. I.e. the charge for paying a bill this month will go on next month's bill. But what if there is no bill next month (because I've cancelled the service the bills were being sent for)? In that case, then Telstra will create a bill containing only the credit card payment fee, decide that it's too low a value to collect, and then send me a statement saying the balance will be carried over to the next month. Once that state is reached, there's no obvious way out - it seems like Telstra are going to spend a $1.00 or so every month telling us we owe them 9c, but not to pay it just yet.

As far as I can work out, this must happen every time someone cancels a Telstra service and then pays the last bill by credit card. In which case, there must be a heck of a lot of these non-bills getting sent each month.

That may explain why Telstra is so keen to revamp it's billing systems.

Posted by Jonno Downes at 04:07 PM | Permalink

In an earlier post, I talked about retailer loyalty programs, and showed how for most retailer loyalty programs, the motivation is to encourage customers to identify themselves to the retailer on each transaction, so the retailer can better understand their customers.

But the most commonly encountered loyalty programs these days seem to be those run by credit card issuers. Alittle thinking on the matter will show there's some major differences between these programs and the retailer loyalty programs I looked at before. The first one being, when you participate in a CC loyalty program, there's no additional plastic card that you need to produce on each transaction - the CC issuer already knows how much you spend on your card, and at what retailer.

Also, unlike in retailer loyalty programs, the rewards you earn are not things that can be written off as marketing expenses by the program owners. Say you sign up for the Dymocks Booklover program, and spend $100 on books. You'll then get $5 to spend the next time you come in to the store. So the net result is that Dymocks have given you a 5% discount in exchange for you first telling them what they need to know in order to more efficiently market to you, and then you coming back to the store and spending more money. This is a win-win.

But When you cash in your ANZ Rewards Visa points for a $100 Harvey World Travel gift card, then ANZ are handing over real money to HWT to pay for that gift card. Probably ANZ will have negotiated a discount from HWT, so they will pay a bit less then the face value of the gift card, but they are still paying out real cash to a 3rd party, which has to be raised from somewhere.

Let's just re-iterate this. Loyalty programs offer credit card issuers no additional information about their customers, and the rewards that they offer cost the issuers real money to provide.

Which begs the question: why on earth would any credit card issuer run such a program? The answer to that comes in two parts. First, every issuer runs these programs because every other issuer does as well, so customers expect to be able to earn rewards. A credit card issuer without a loyalty program would be like a peacock without a brightly coloured tail.

The second part to the answer is, issuers can afford to run these programs because they are able to push the cost of the rewards on to the merchants where you use your credit card. When a credit card is used to pay for goods, the merchant who has accepted the card ends up paying their acquiring bank a fee called a Merchant Service Fee, that will usually be between 1% and 5% of the total payment. The acquiring bank then splits this fee with the issuing bank. In other words, whenever you pay for something on a credit card, up to 5% of what is charged to your card ends up going to the banks processing the transactions, not to the retailer who provided the goods or services. If you paid by debit card (i.e. chose 'cheque' or 'savings' on the EFTPOS terminal) then there would still be a fee charged to the merchant and split between the acquirer and issuer, but the fee would be a flat fee (somewhere between 20c and $1.00). So when you pop out to your local hardware and spend $400 on a new lawn mower, whether you press press 'savings' and 'credit' on the EFTPOS terminal can mean either and extra $20 margin going to the hardware store or else, $10 each in fees to the acquiring and issuing banks. Assuming you have the money in your savings account, and you're going to pay your credit card off in full at the end of the month anyway, why would you press 'credit' (and give that $20 to the banks) instead of 'savings' (and let the hardware store keep it)? Well one thing that might sway your mind is the fact that choosing 'credit' will earn you some rewards points, whereas choosing 'savings' won't.

In other words, loyalty programs are a way of encouraging people to favour one payment method (credit cards) over another (debit cards) that are transacted and settled in exactly the same way but have very different fee structures. The credit card issuers can 'bribe' people to pay by credit cards, and fund that through the merchant services fees they charge (Since both the value of rewards you earn, and the fees you earn for the bank that issued your credit card are directly proportionate to the value of goods and services you pay for using your credit card.)

So the merchants in turn know that a reasonable percentage of their customers will pay by credit cards, and so when they are working out what price to charge, they will factor in the merchant service fees.

So the net result is, everyone ends up paying (slightly) higher prices to cover the cost of credit card loyalty programs. This is something the RBA has noticed, and is working to address.

Posted by Jonno Downes at 01:30 AM | Permalink

I only just realised this while talking tonight with James from Decillion, but any settlement process should always involve an odd number of parties.

To prove it, we'll first need some definitions:

Call the party that owes money the debtor
Call the party that is owed money the creditor
Call the party that holds the account the debtor will pay out of, the debtor's settlement agent
Call the party that holds the account the creditor will be paid in to, the creditor's settlement agent

The simplest case is if the debtor and the creditor both hold accounts at the same insitution. Then there are 3 parties - the debtor, the creditor, and the single insitution that acts as settlement agent for both parties .

If the debtor and the creditor do NOT hold accounts at the same institution, then settling between the debtor and the creditor creates a debt between the two agents. I.e. the debtor's settlement agent itself becomes a debtor to the creditor's settlement agent, and that debt needs to be settled using  accounts held at some third insitutution in the name of the agents.

So settlement is a recursive function, and each level of recursion adds 2 parties, while  the final call adds 1. And 2*n+1 is always odd for an integer value of n.

Here's the settlement algorithm as pseudo C#

static void SettleDebt(Party creditor, Party debtor, double amount) {
    if (creditor.SettlementAgent == debtor.SettlementAgent)
    {
        Party agent = creditor.SettlementAgent;
        agent.FindAccount(debtor).Balance -= amount;
        agent.FindAccount(creditor).Balance += amount;
    } else  {
        SettleDebt(creditor.SettlementAgent, debtor.SettlementAgent, amount);
        debtor.SettlementAgent.FindAccount(debtor).Balance -= amount;
        creditor.SettlementAgent.FindAccount(creditor).Balance += amount;
    }
}

Let's apply this to direct deposit transactions, and assume Alice has bought a 2nd hand copy of Applied Cryptography on eBay, so she need's to transfer $98.36 to Bob. Also assume Alice banks at the CBA. She uses the CBA website to initiate a transfer to Bob's account.

If Bob also banks at the CBA, then the settlement process is completed by CBA updating it's record of the current balance of both Alice's and Bob's accounts. In this case there are a total of 3 parties involved (Bob,Alice, the CBA).

But if Bob's account is at NAB, then as well as both NAB and CBA updating their records of Bob's and Alice's accounts, a debt is created beween NAB and CBA that gets settled by the RBA updating the NAB and CBA Exchange Settlement accounts. That makes a total of 5 parties (Bob,Alice, the CBA,NAB and the RBA).

I haven't talked about transfers to overseas accounts yet, so for the moment I'll just confirm there can be 7 parties to the transaction, one of them being the Bank for International Settlements, and interested readers can fill in the blanks themselves.

Posted by Jonno Downes at 10:12 PM | Permalink | Comments (2)

It seems like every time I go into a shop or open my mail I get asked to join a loyalty program of some sort or other. This post looks at why they are so popular (both with retailers and consumers) and also looks at how they are implemented.

Organisations generally have 2 motiviations for creating loyalty programs. They either want to understand what their customers are doing, or they want to change what their customers are doing (i.e. by encouraging people to buy more goods & services), or both.

The organisations that are most prominent in running loyalty programs are retailers, credit card providers and airlines (i.e. 'frequent flyer' programs). The blend of motivations, and the implementations, differ between these groups, so in this post we'll just be looking at retailers who sell things like clothes and groceries to individual consumers. In a later post I'll look at how and why credit card and airline loyalty programs differ.

For most retailers, loyalty programs are all about being able to track what customers are doing. Any modern POS system will be able to report on how much of each product has been sold, but retailers also want to know who has been buying each different product, so they can tailor their marketing appropriately. The problem is, in an ordinary retailer payment transaction, there is no way for the POS to capture anything about the identity of the purchaser.

By giving customers a plastic card with a unique ID encoded on it, and encouraging the customer to produce that card every time they make a purchase, retailers get to associate purchases made at different times and at different stores with the one customer. They also will have made the customer provide their name, address and other demographic data at time of signup. This means the retailer can work out e.g. what models of leaf blowers are most popular with married male self-funded retirees (and therefore should be advertised in Holding Hands in an Autumn Breeze - The Magazine For Married Male Self-funded Retirees Looking for a Leaf Blower).

The incentive for consumers to first, tell retailers who they are, where they live, and how much money they have, and second, hand over that bit of plastic with their unique ID on it everytime they front up at a POS, is that the retailer offers rewards to people willing to participate in this data-collection exercise.

For some retailers, the reward takes the form of a discount made at the time of the initial purchase. These rewards are certainly easy to implement. But other retailers have decided that the cost of administering a more complex reward and redemption system is worth the benefit of making the customer come back later to use their reward. The ideal result here is if the retailer can motivate you to take your reward in the form of a discount towards something that you wouldn't have otherwise bought.

Putting it all together, a typical retailer loyalty program looks like this:

• A customer signs up to a retailer's loyalty program, and in the process provides demographic data. The retailer stores this data in a database, associates the customer record with a unique ID, encodes that unique ID on a plastic card, and mails the card to the customer.
• Whenever the customer buys goods from that retailer, they present their card, which is swiped through the POS. The POS captures their unique ID, and forwards that ID along details of individual items purchased on to a central tracking database.
• Data from the tracking database goes in to a data warehouse, that is used by marketing analysts to see who they typical customers are for different products. This information is used to tailer marketing and advertising programs.
• At regular periods (most frequently this is quarterly), a process will be run to work out how many rewards each customer has earnt. Usually the rewards earned are directly proportionate to the total value of goods purchased with that retailer.
• Once the reward values have been calculated, a letter will be sent out to the customer telling them what their reward is. Often this letter will also include marketing material tailored to this specific customer. Remember the whole point of the program is to let the retailer know exactly what each person buys.
• As well as telling customers the value of rewards earnt, the mailout will also include information about how the rewards can be redeemed. In a few cases (e.g. FlyBuys) the rewards are redeemed by selecting goods or services from a catalogue, and either dialing a call centre or using a web application to redeem rewards for the selected goods. This style of redemption is generally only used for programs (like FlyBuys) that are not specific to a single retailer. It is far more common for the rewards to be presented in the form of a voucher or gift card that must be presented in store, that way the retailer has the opportunity to sell you more stuff while you are there.

If we look at the economics of a single retailer program, we'll see that costs fall into these areas:

• System Development & Maintenance - The original loyalty programs where all in-house custom development jobs run by major retailers who are able to amortise the development costs over hundreds of stores. Nowadays the tracking and analysis components of loyalty programs are becoming available as off the shelf products
• Marketing Data Analysis Loyalty Programs generate a heap of data, and it takes a lot of MBA graduates with wizard-level Excel skills to turn that data into useful knowledge about customers. But any retailer thinking about a loyalty program will probably already be spending a lot on market analysis anyway.
• Funding The Rewards - In the best case, customers will spend their rewards on things they wouldn't otherwise buy, and thus running a loyalty program can fund itself by leading to increased sales. Alternatively, with the right market analysis (to identify what products each customer is most interested), and a good relationship with the suppliers, it may be possible for retailers to reward customers entirely with discounts funded by suppliers (e.g. find people who buy a lot of Schick razors, then tap Gillette for some marketing funds to send those people coupons worth 50% off Gillette razors. ) In the worst case however, retailers will end up giving a discount to customers on items that the customer was going to buy anyway. In other words, like any discount program, there is always the risk that loyalty programs can lead to an erosion of margins without any corresponding uplift in volumes.

So there's lots of room for risks of cost blowout and margin erosion, and potentially a lot of reward in the form of improved market intelligence. As loyalty programs evolve in to an off-the-shelf product, a lot of the risks are being diminished, although the potential for a loyalty program to offer any competitive advantage is also diminished at the same rate.

In fact as loyalty programs become more and more ubiquitous they also become less and less useful, to the point where they can become an essential cost that all market participants have to wear, but non derive any benefit from. In my next post on this topic, I'll look at how this has happened to airline and credit card loyalty programs.

Posted by Jonno Downes at 11:03 PM | Permalink | TrackBacks (2)

A year a go, I transferred my phone line away from Telstra (as part of a special deal on ADSL, nothing personal against Telstra). When I made my final payment I must have entered the wrong amount, since Telstra think I still owe them 56 cents.

They obviously have implemented some logic in their billing system that tries to prevent collecting fees when the cost of collecting the payment would exceed the value being collected.

The problem is, since I've cancelled my service, I'm not generating any more charges. So every month Telstra sends me a letter advising me that I owe them $0.56, but telling me not to pay it yet.

I wonder if this will go on until I die.

Posted by Jonno Downes at 08:03 PM | Permalink | TrackBacks (1)

This is part 6 of a series on Australian Payment Systems.

In this post I talk about the legal framework that governs payments in Australia.

Money in Australia is controlled by the federal government.The parliament has delegated control (through the Reserve Bank Act 1959) over 'monetary policy' to the Reserve Bank of Australia (RBA).

That means the RBA decides how much money should exist within the country.[1].

Money can exist in one of two forms. It can either be 'cash' (notes or coins), or it can be 'electronic' money.

Regulating the supply of cash is fairly simple - Apart from negligable amounts of conterfeiting and lost/destroyed notes, the amount of cash circulating is however much the RBA prints. There is a physical token (i.e. the banknote or coin) that gets transferred along with ownership of the money. Since the token can only ever be in one place, it's obvious who is the owner of any money that is in the form of cash.

But the whole point of 'electronic' money is that it is not represented by physical tokens, so payments can be made instantaneously over great distances, and huge quantities of money can be accumulated and transferred without needing to be stored in Giant Vaults.

So the RBA wants electronic money to circulate freely, but also it wants to ensure that it is never created or destroyed by anybody else.

One way of achieving this would be for the RBA to hold a single database that records how much electronic money every individual person or business holds, and for that database to be updated whenever any electronic money is transferred between two parties. This would ensure that any 'credit' to one persons account is matched by a 'debit' to another account. But it would also mean the RBA would have to nationalise the entire retail banking sector and run every ATM machine and EFTPOS terminal. Which is a lot of work, and after the Australia Card debacle it was obvious that folks just aren't happy with that kind of centralised government control.

So instead we have a 'federated' system. Individual bank accounts are managed by a small number of 'Authorised Deposit-taking Institutions' (ADI's). Each ADI is responsible for managing a pool of money. Each institution runs their own database that records how much money belongs to each individual account, while the total money held by each ADI is tracked by the RBA. A movement of money between 2 accounts held at the one ADI is performed by the ADI modifying the records in it's own database. Any movement of money between accounts held at 2 different ADI's (i.e. a BECS direct deposit or a CECS/EFTPOS payment requires the RBA to be notified of the movement of funds between the ADI's. Note the RBA gets notified only of the net daily movements between ADI's, it doesn't know or care which individual sent or received the money, only the ADI's know that.

This system puts a lot of trust in the ADI's, so to ensure that the ADI's are trustworthy, they are regulated by APRA - the Australian Prudential Regulation Authority. They make sure that ADI's are honest, have good record keeping, and don't do silly things with the funds that people have deposited with them. The federal government has mandated (via the Banking Act 1959 that only APRA regulated ADI's can hold 'deposits' on behalf of other people. In a later post I'll look at what this means for anyone planning on building a new payment or stored-value system in Australia (such as gift cards).

The other big player in Australian Payment Systems is APCA - the Australian Payments Clearing Association. This is basically a co-op created by the major banks. It is not a government agency or have any particular status under legislation, however it publishes the rules and file specifications used in processing BECS and EFTPOS transactions. It also sets the rules and regulations under which cheques get settled.

Footnotes

• [1] 'money' is not the same thing as wealth

Posted by Jonno Downes at 02:35 PM | Permalink

So far in this series on Australian Payment Systems I've talked about 3 payment systems - BECS (for transferring money between 2 australian bank accounts), EFTPOS (aka CECS) for debit & credit card processing, and RITS (used to perform 'high value' transfers in real-time).

I've also shown how both BECS & CECS end up settling through RITS, and I've shown how the processing & settlement of BECS & CECS transactions is done on a peer to peer basis. In other words, each participant needs to setup both a legal agreement and a communications link with every other participant. (In network-speak, this is called a fully connected topology)

This means that any financial institution that wants to let it's customers send direct entries, or wants to issue a credit card, needs to have a couple of racks of comms gear, a bevy of prime grade server wranglers, and some good commercial lawyers.

While that kind of overhead is no sweat at all for CBA, it's a bit of a stretch for a single office credit union with 2.75 employees. So there are a number of organisations that act as 'aggregators' in to BECS & CECS. For example, most credit unions will use either CUSCAL or CreditLink as an agent for processing BECS direct entries.

Each credit union is assigned a BSB, where the first 2 digits (the 'Bank' part) points to the aggregator that acutally peers with the banks. The aggregator is responsible for collating all the individual outbound transactions from each credit union, and forwarding on any inbound transactions, and performing any settlement.

The aggregators settle with the banks via their Exchange Settlement Accounts (ESAs) at the RBA. The aggregators don't have accounts for individual customers, instead they track the balance of each credit unions total funds. (i.e. there will be one account at the aggregator for each credit union). Then each credit union is responsible for tracking how their total funds at the aggregator is divided up in to individual customer accounts.

Posted by Jonno Downes at 08:54 PM | Permalink

This is part 4 of a series on Australian payment systems.

This post describes the Australian EFTPOS system, also known as CECS. The one infrastructure is used to process both credit cards and debit cards. [1]

First we'll start with some definitions. In an EFTPOS transaction, there are 4 important participants

• the 'card holder' - the person who wants to buy some goods and pay for it with their card
• the 'card acceptor' - the merchant who wants to take payment for goods
• the 'card issuer' - the bank that issued the debit or credit card to the card holder (i.e. the cardholder's bank)
• the 'acquiring bank' - the bank that runs the EFTPOS terminal issued to the card acceptor (i.e. the merchants bank)

First off, the card gets swiped through the EFTPOS terminal (aka a PINpad) which reads the card number off the magnetic stripe on the back. Then the merchant enters in the amount to charge the card and the cardholder selects what account to pay with, and (if necessary) enters a PIN. The EFTPOS terminal then connects through to a computer (called an 'EFTPOS Switch') at the merchant's bank. This connection can be over PSTN, or ISDN, or X.25 or even IP. There are lots of different communication protocols in use, however in all cases, the message will be encoded into a message format called AS2805. Like many things labelled 'Australian', AS2805 actually comes from overseas - it's a dialect of ISO8583.

Once the transaction gets the 'acquiring' bank (i.e. the bank that issued the terminal to the merchant), the acquiring EFTPOS Switch then looks in the AS2805 message, and pulls out the first 6 digits of the card number. These 6 digits are called a Bank Identification Number (BIN). This tells the acquirer which bank issued the card. The acquirer then looks up a routing table to see if the acquirer has an 'interchange agreement' with that card issuer. I.e. is there a way for the acquirer to both send the transaction on to the issuer, and also (later) settle the transaction with the issuer. If the answer to both questions is yes, then the acquiring switchs sends the transaction on to the issuer's switch, the issuer's switch then looks up the relevant card record in it's database, checks the account balance and PIN and what not, and decides whether to approve or decline the transaction. The response is then put in to another AS2805 message that gets sent by the issuer switch to the acquiring switch, the acquiring switch forwards the response on to the terminal that initiated the transaction, and then the terminal prints out a receipt. At this point then:

1. the cardholder has gotten some goods from the merchant,and
2. the cardholder has had money taken out of their account by the card issuer.

   But there's still 2 more steps that need to happen before the transaction is complete:

3. the card issuer needs to transfer money to the acquirer
4. the acquirer needs to credit the merchant's account

In other words, the transaction has been processed (sometimes called cleared) but not yet settled. Like BECS, EFTPOS transactions use a 'Deferred Net Settlement'process. Overnight, each acquirer summarizes the previous days EFTPOS transactions and calculates it's net position with each issuer (and issuers likewise calculate their net position with each acquirer), and then transactions are posted in to RITS to move the net total from each issuer's ESA to each acquirer's ESA.

The acquirer then splits up the total sum transferred to it's ESA across all the merchants who performed transactions, using it's own switch's record of transactions processed on that trading day.

Footnotes

• [1] There are some differences between paying by Credit Card (VISA/MasterCard) and paying by Debit Card (i.e. when you select cheque or savings), although mostly though these differences affect the rate that the merchant gets charged for the privilege of accepting EFTPOS payments, not the communication or settlement of the transactions so we'll ignore those for the moment and group all the different types of EFTPOS transactions together.

Posted by Jonno Downes at 10:47 AM | Permalink

(via Schneier on Security) - FedEx Kinko's Payment Card Hacked

The whole notion of using 'smart cards' for stored value has never made any sense to me. This seems to be a particularly lame implementation, but even if you have enough faith in your crypto to be confident that people holding your cards can't work out a way to modify the values on them, the economics of smart cards still don't seem to stack up.

Depending on the volume of cards you are buying, you might get the cost of your smart cards down to say $1 personalised. Compare that to a standard 'mag stripe' card, which you can get in bulk at maybe 10c personalised. That 90c price difference is pretty hefty on a card that might only ever be loaded with $5.00

In theory, a smart card will let you save the cost of communicating with a central server on each transaction. But unless you're putting a vending machine in Antarctica, and the only option for calling home is via Iridium, the comms cost of a typical 1KB transaction is going to be a fraction of a cent.

This not to say that smart cards can't be add value to systems built on real-time central authorisation. Tamper-resistant smart cards storing personalised private keys can go a long way to cutting out the cloning which is the biggest risk to ordinary mag-stripe stored value systems. But in this age of broadband everywhere, there's just no excuse not to be doing real-time validation of each transaction against a central db.

Posted by Jonno Downes at 12:18 AM | Permalink

This is part 3 of a series on Australian payment systems.

In the last post, I talked about 'Deferred Net Settlement', which is when each bank aggregates a days transactions, and then settles with each other bank the net total of all the days transactions with that other bank. In other words, 100,000 individual transfers might be rolled up in to one single inter-bank payment.

This approach is used for a couple of reasons:

1. It minimises the number of inter-organisation transfers of data (remember, this system evolved in the days when exchanging data with another organisation meant handing over big ol' mofo tapes.
2. It minimises the number of transfers between Electronic Settlement Accounts (ESAs) held by the RBA. As we'll see below, these transfers need manual authorisation.
3. The banks get to play with money being transferred for up to a 3 days before handing it over to it's final destination [1]

But some people just can't wait that long. When an investment fund screen-jockey likes his razor so much that he buys the company (or at least, $100M worth of shares in it), then the daily interest on the payment would be enough to buy a new car. Maybe not a beemer, but certainly a nice shiny yellow barina (with air) so the missus can pop out to the hairdresser [2]. And you don't get to be a Big Swinging Dick by leaving money on the table.

So the RBA runs a system called RITS - the Reserve Bank Information and Transfer System. This is currently an old-skool text-mode application. Any time a transfer is requested through this system, information about the transaction needs to be entered by both parties involved in the transaction. Only if both parties enter the same information will the transaction be processed. This stops the kind of massively expensive stuffups that can follow on from seemingly trivial typos.

As soon as both parties have authorised a transfer, and the RBA has confirmed there are enough funds in the ESA that the money is coming out of, the current balance of each party's ESA is adjusted. Each RITS transfer is acted on immediately, there is no batching netting of multiple transactions. This makes RITS a 'Real Time Gross Settlement' (RTGS) system.

RITS also has a number of 'feeder systems' that can post transactions in to RITS, which I will discuss in a later post. The daily net positions for BECS direct entry transactions are also batch loaded in to RITS.

So now let's follow a direct deposit transaction through the systems again to see how everything hangs together.

First, I use the Bank 1 website to request a $106.98 transfer. I enter the BSB assigned to a branch of Bank 2, and the account number of a customer of that branch. Immediately, Bank 1 debits my account balance (stored in the database they control) and stores somewhere the fact that there is a direct deposit to be processed overnight.

Overnight, Bank 1's BECS processing application gets this transaction, and puts it in a file along with all the other BECS direct entry transactions initiated by Bank 1 customers to be sent to Bank 2. This file then gets sent (most likely via FTP) to Bank 2. Bank 1 and Bank 2 the independantly calculate the net movement of money between Bank 1 and Bank 2, and notify the RBA (via RITS) what amount needs to be settled. The RBA adjusts the ESA balances belonging to both Bank 1 and Bank 2, and finally bank 2 adjusts the record of the recipient's bank account, stored in the database that bank 2 runs. Finally, when the recipient logs in to their banking website, they will see that their balance has been increased.

Simple, really.

Next post I will talk about the CECS system used for processing credit card and debit card transactions via EFTPOS.

Footnotes

• [1] By 'play' I mean 'invest in the short term money market', not 'pile up in a big heap and roll around in'.
• [2] RRP is current at time of writing and may change without notice. Does not include on road costs or dealer delivery charges.

Posted by Jonno Downes at 01:10 PM | Permalink | Comments (5) | TrackBacks (2)

I'm putting together a collection of posts that describe payment systems in Australia.

This is what I've done so far

• part 1 introduces the RBA and Exchange Settlement Accounts
• part 2 describes BECS (direct entry) and introduces 'Deferred Net Settlement'
• part 3 is on Real Time Gross Settlement, and introduces RITS
• part 4 is about EFTPOS transactions (aka CECS)
• part 5 talks about how smaller institutions participate
• part 6 is a brief overview on how these systems are regulated
• part 7 will look at 'alternative' payment methods like paypal
• part 8 will look at international exchanges, and the role of SWIFT and the CLS Bank

I'm not going to describe the cheque clearing system because it's boring & complex and will hopefully go away soon. 

Here's some other useful resources in understanding payment systems:

• Wikipedia
• APCA - publish the rules that govern most of the payment systems in Australia
• Alan L Tyree describes the legislative framework for Australian payment systems

 

Posted by Jonno Downes at 02:18 PM | Permalink | Comments (2) | TrackBacks (5)

This post I'll look at the simplest electronic payment system in Australia - BECS

But first a quick review - last post I gave an overview of Exchange Settlement Accounts (ESAs), held by the RBA, and showed how a bank's "money" is split between cash and it's ESA balance. All the "money" in Australia always exists in one of three forms. It can be

1. 'Circulating' as cash (in your wallet, down the back of the sofa, tucked in to a stripper's g-string), OR
2. A deposit held by a bank as cash, OR
3. A deposit held in a bank's ESA.

And remember, that where the money 'is' is different from who 'owns' the money. The money I own is split between what's in my wallet, and what I have deposited with a bank. When I deposit my money with a bank, some of that money stays as cash, some forms part of the bank's ESA, but it is still all 'my' money, up until I succumb to neighbourhood pressure and buy a leaf blower, at which point ownership of some of that money passes to the seller of the leaf blower.

If I go to a store and pay by cash, then everything is simple - notes come out out of my wallet, and go in to the till at the hardware store. But what if I succumb to the temptations of eBay, and then the seller wants me to pay by direct deposit? This is what happens.

First, I need to tell the bank that I want to make a transfer from my savings account to the sellers account. I tell this to the bank by using an application they have provided ('back in the day', this would be using desktop application, such as Westpac's DeskBank product, and a dialup modem connection to the bank, now it's most likely done through the banks website). When I lodge the request, I specify the amount to transfer, the account (owned by me) that I want to transfer money out of, and the account (owned by somebody else) that I want to transfer money to. In Australia, the bank account is specified in 2 parts. First, there is a 'BSB' number, and then there is an account number. BSB stands for 'Bank/State/Branch'and it's a 6 digit number. The first 2 digits uniquely specify the bank as a whole, the remaining 4 digits specify the branch within that bank. (originally, the 3 digit specified the State the branch was in, i.e. xx2xxx was NSW,xx3xxx was VIC etc but that appears to no longer be enforced). The list of BSB numbers is maintained by APCA. The BSB is to a bank account number what an area code is to a phone number.

As soon as I send the transfer request to my bank, the bank will debit my account, and transfer that money to another internal holding account within the same bank. Then overnight, each bank gathers up all of the days direct debit & direct deposit requests, and groups them by the destination bank (i.e. by the first 2 digits of the BSB).All the banks then exchange files with each other, i.e. CBA will send to Westpac a file containing all the transfers initiated by Westpac customers to CBA accounts, CBA will send another file to Westpac with all the transfers initiated from CBA accounts to Westpac, etc. Each bank needs to set up it's own transfer arrangement with every other bank[1]. Originally these exchanges would involve representatives from all the banks getting together and swapping magnetic tapes - nowadays the files will be transmitted using FTP or equivalent . The files are formatted according to a specification put out by the Australian Payments Clearing Association. The spec itself is 'confidential' but it's obviously a COBOL era design - there's a footer and trailer record, each record starts with a 2 digit 'record type', has fixed width fields and ends with a line break.

After the banks have exchanged the files containing the individual transfers, each bank calculates it's 'Net Position' with each other bank. This is the net movement of money between those 2 banks. i.e. if Westpac customers have transferred a total of $500,000 to CBA customers, and CBA customers have transferred a total of $650,000 to Westpac customers, then the 'Net Position' between CBA and Westpac is that CBA owes Westpac $150,000. This position needs to be settled before any of the individual transfers can be applied to individual bank accounts. This settlement happens by both banks telling the RBA what the movement of money should be, and if both banks tell the RBA the same thing, then the RBA will debit CBA's ESA balance by $150,000, and credit Westpac's ESA with $150,000. Once all these adjustments have been made, each bank can then apply the transactions specified in the files they have received, and credit their individual account holders.

This type of system, where there is a single daily movement of money to settle a whole bunch of individual transactions is called a Deferred Net Settlement (DNS) system. i.e. Settlement of transactions is done seperately from communicating details of the transaction, and the settlement is done on a net basis.

In the next post, I'll talk about the other type of settlement systems, called Real Time Gross Settlement (RTGS) system, and show how the final settlement under a DNS system ends up being a single RTGS transaction.

Footnotes

• [1] I'm only talking about the 'top tier' banks here, e.g. Westpac/NAB/ANZ/CBA/St George. I'll talk about how the other banks & building societies do things in another post

Posted by Jonno Downes at 01:33 PM | Permalink | Comments (2) | TrackBacks (6)

Money in australia exists in one of two forms - as cash (coins and banknotes) or in bank accounts, which (shush! don't tell anyone!) are really just records in a computer somewhere. When a payment is made, then either cash changes hands, or else the computer records are updated to debit one account and credit the other.

This is part 1 of a series of posts that give a brief introduction to what those computer systems are that store the bank accounts, and how the records get updated.

The first, and most important, player in payment systems in Australia is the Reserve Bank of Australia. Most people would know the RBA's role in setting interest rates and Money Supply), but it also makes sure that all the banks play nicely with each other, that they don't invent money of their own, that they aren't about to go bust and take your grandmother's life savings with them.

It can do this because the RBA is actually the bank where other banks have to keep their money. Or to put it another way, it's the RBA that tells the other banks how much 'electronic' money they actually have. Each bank has an account at the RBA called an Exchange Settlement Account. These Exchange Settlement Accounts (ESAs) get updated when banks transfer money between each other (in which case on ESA gets credited, the other debited - we'll look at this in more detail in the next post), or when a bank gets issued some bank notes (in which case it's ESA will be debited for the value of the notes issued ) or when a bank hands some soiled notes back to the RBA to be destroyed (in which case it's ESA will be credited for the value of the notes returned).

So the total amount of money that a bank has (i.e. the money it is holding on behalf of it's account holders) should be the sum of

1. all the notes and coins the bank has in it's vaults, plus
2. the value of the ESA held for that bank at the RBA, plus
3. the value of any assets the bank has invested in

For the rest of this discussion, I'm going to ignore any invests the bank has, and assume it keeps all it's money in notes or in the RBA (since these investments don't have any bearing on how the payment systems work).

So lets look at what happens when I go to my local branch of the bank to deposit the winnings from last friday night's poker game.

Before I start, my "savings" account has $614.57 in it, and my cheque account has $12.19. The bank has taken total of $1,000,000,000 in deposits, including my $614.57+$12.19=$626.76. Of this, $200,000,000.00 is stored as notes and coins in bank vaults around the country, hile the remaining $800,000,000.00 exists only as the current balance of the banks ESA.

I go to the bank, and hand over my $8.62, and the teller takes my notes and coins, makes sure they're not fraudulent and puts them in her cash drawer. She then records the deposit, and the bank updates it's record of my savings account balance to be $614.57+$8.62=$623.19. The bank now holds bank accounts totalling $1,000,000,008.62, of which $200,000,008.62 is stored in cash, with the remaining $800,000,000.00 being the current balance of the the banks ESA.

I then decide I will put my winnings towards a new leaf blower that I plan to pay for with a cheque, so while I am in the branch, I transfer $100 from my savings account to my cheque account. The bank updates it's record of my savings account to be $523.19, and my cheque account to be $112.19. However the total of all accounts held at this bank does not change, so there is no change to the totals of the banks cash on hand or it's ESA balance.

But unfortunately, part of my winnings was a $5 note that has been through the wash too many times, and the bank decides to retire that note. The note gets sent back to the RBA, so the bank now has a total of $200,000,003.62 in cash, and the RBA adjusts the bank's ESA balance to be $800,000,005.00

The important thing to notice is that the only thing that affects the total amount of money the bank has is when an individual account holder makes a deposit or withdrawal, but the split between money held as cash and money held in in the ESA  at the RBA can change without affecting any individual's bank balance, and moving  money between accounts held at one bank doesn't affect cash on hand or the bank's ESA.

That's enough of an introduction to the relationship between individual accounts, a bank's cash reserves, and the RBA. Next post, I'll look at how money moves between accounts held at different banks, starting with the system called BECS, which is used to handle 'Direct Deposits' (for paying salary straight into people's bank accounts) and and 'Direct Debits' (for paying for that gym membership that you never use).

Posted by Jonno Downes at 10:44 PM | Permalink | TrackBacks (4)