« February 2006 | Main | June 2006 »

March 31, 2006

just asking

Guy Kawasaki wants links and questions. I'm happy to oblige.

My question is multiple choice. Is it better to

a) found a startup, OR
b) join a startup that's got enough runs on the board to be clearly viable, OR
c) go to a big established company, but in a new division that's in startup mode

I know the answer is "different strokes for different folks", I'm still interested to hear what the pros & cons are for different people.

Just for the record, I chose option C - as of monday, I'll be working for Woolworths Financial Services.

That means Coles Myer will be my competition (how good's that? 2 links for the price of one!)

March 24, 2006

everything old is new again

over the last few days, there's been a lot of buzz about PayPal mobile.

I must be turning into a fuddy duddy cos I just don't get what's novel about being able to use your phone to do a money transfer, or use your phone to pay a retailer, or use your phone to order things out of a catalogue.

The only new thing I see is that PayPal are cutting out the requirement to authenticate yourself when making a payment by phone, instead they seem to be trusting Caller ID. As Bruce Schneier points out, this is probably not a safe thing to do.

I don't mean to belittle whoever built this thing, I'm sure it was a lot of fun to work on, with all sorts of interesting challenges to overcome and fun toys to play with. Maybe Cameron Reilly will set me straight on this, but I just don't see what problem this product is actually solving. (BTW Cameron, I'm still game to make that bet if you are)

 Updated 2006-03-24 - It has been suggested in some quarters that PayPal is safe because SMS can't be spoofed. Look Harder, Homer!

March 22, 2006

market consolidation (again)

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.

March 19, 2006

network effects in australian retail

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.

March 17, 2006

more predictions on payments

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).

March 15, 2006

reading the tea-leaves on payment systems

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.

Where POS data goes (and where it stops)

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.

how IE responds to different HTTP status codes

There is a discussion on intertwingly about feed errors, including the case where a server was serving a valid RSS feed with a 404 (file not found) status code. The feedvalidator was reporting the feed as being non-existent, but IE and firefox would happily display the XML.

I was curious to see how IE handled all the different HTTP status codes, so I put together some ruby scripts to test them.

this is the server: it just listens on port 2000, looks for a 3 digit number in the requested path, and if it finds one returns that number as the HTTP status code in the response, along with a little html page.

require 'webrick'
include WEBrick
s=HTTPServer.new(
 :Port=>2000
)
trap ("INT") {s.shutdown}
s.mount_proc('/') {|req,resp|
     req.path=~/(\d{3})/
     @status=$1?$1:200 
     resp.body="<HTML><body>request:<pre>#{req}</pre>Status:#{@status}<p>#OK#</body></html>"
     resp.status = @status
}
s.start

and this is the client, which uses watir to get IE to call the server, and check the result:

require 'watir'
def test_status(ie,status)
 
 begin
  ie.goto("
http://localhost:2000/#{status}")
  @result=ie.contains_text("#OK")?'OK':'FAIL'
 rescue
  @result='FAIL'
 end
 
 puts "STATUS #{status} -
#{@result}"
end

#list of status codes from http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
#skip 1xx since they causes the client to wait for the server to send a further response
#skip 204 NO CONTENT - watir blocks
#skip 301 / 302  - watir blocks (probably looking for a Location field - according to spec it's not actually mandatory)

ie=Watir::IE.new

%w(
 200 201 202 203 205 206
 300 303 304 305 306 307
 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417
 500 501 502 503 504 505
).each {|status| test_status(ie,status)}

ie.close 

Here's the result in IE 6, with 'friendly http errors' disabled ('OK' means that IE rendered the HTML returned, 'FAIL' means IE displayed an error message instead):

STATUS 200 - OK
STATUS 201 - OK
STATUS 202 - OK
STATUS 203 - OK
STATUS 205 - OK
STATUS 206 - OK
STATUS 300 - OK
STATUS 303 - FAIL
STATUS 304 - OK
STATUS 305 - OK
STATUS 306 - OK
STATUS 307 - FAIL
STATUS 400 - OK
STATUS 401 - OK
STATUS 402 - OK
STATUS 403 - OK
STATUS 404 - OK
STATUS 405 - OK
STATUS 406 - OK
STATUS 407 - OK
STATUS 408 - OK
STATUS 409 - OK
STATUS 410 - OK
STATUS 411 - OK
STATUS 412 - OK
STATUS 413 - OK
STATUS 414 - OK
STATUS 415 - OK
STATUS 416 - OK
STATUS 417 - OK
STATUS 500 - OK
STATUS 501 - OK
STATUS 502 - OK
STATUS 503 - OK
STATUS 504 - OK
STATUS 505 - OK

If friendly errors are turned on, this is the result:

STATUS 200 - OK
STATUS 201 - OK
STATUS 202 - OK
STATUS 203 - OK
STATUS 205 - OK
STATUS 206 - OK
STATUS 300 - OK
STATUS 303 - FAIL
STATUS 304 - OK
STATUS 305 - OK
STATUS 306 - OK
STATUS 307 - FAIL
STATUS 400 - FAIL
STATUS 401 - OK
STATUS 402 - OK
STATUS 403 - OK
STATUS 404 - FAIL
STATUS 405 - OK
STATUS 406 - FAIL
STATUS 407 - OK
STATUS 408 - FAIL
STATUS 409 - FAIL
STATUS 410 - OK
STATUS 411 - OK
STATUS 412 - OK
STATUS 413 - OK
STATUS 414 - OK
STATUS 415 - OK
STATUS 416 - OK
STATUS 417 - OK
STATUS 500 - FAIL
STATUS 501 - FAIL
STATUS 502 - OK
STATUS 503 - OK
STATUS 504 - OK
STATUS 505 - FAIL

 

March 14, 2006

roundup 2006-03-14

Interviewing Ruby Programmers

If Architects had to work like Programmers (via Karl's Blog)

 

when business rules collide

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.

Credit Card Loyalty Programs

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.

March 13, 2006

roundup 2006-03-13

not much action here lately, I've been otherwise engaged.

Last night I did a quick catchup on 7 days of unread blogs while watching the greatest cricket match ever, here's some highlights (of blog reading, not the game).

With Pants Come Dignity - worth the price of admission for the name alone

If you can only get to one conference this year, make sure it's Waterfall 2006 - Dead Fish Can't Swim But They Can Float Down a Waterfall

Signals vs Noise on 'the cost of bootstrapping your app' (via The Sydney Hacker). See also SvN on 'revealing hidden assumptions in estimation'

March 07, 2006

poised over the pause button

I won't be posting much this week, since Angela and I are about to embark on our 'official' honeymoon.

First stop, Adelaide, where we'll be seeing Tegan launch her new book.

March 06, 2006

Settlement is Odd

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.

daily roundup 2006-03-06

From TechTalk - Cameron's Brain: ALEXANDER DOWNER CHALLENGED TO LIE DETECTOR TEST. This is a brilliant bit of media hacking. Memetastic!

Both Bill de hÓra and Tim Bray are pointing at an awesome collection of Drunken Blog Rants by Steve Yegge - an ex-Amazonion, now Googleite. If this is the future, and you found this page cos I'm the guy who's going to interview you next, pay close attention to The Five Essential Phone-Screen Questions. (Note to future me: pay attention to that link as well). Other highlights - Being the Averagest and What You Need To Know. PS - I am going to staple a copy of The Nonesuch Beast to my forehead.

 

March 05, 2006

Retailer Loyalty Programs

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.

Components in a typical retailer loyalty program

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.

Nice idea, needs some tweaks

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.


My monthly Telstra non-bill

How Australian Payment Systems are regulated

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

Techtalk Highlights 2006-03-05

So far today on TechTalk, the best I've seen is secretGeek's cautionary tale on why you should Never BCC an Idiot

StillHQ has a great introduction to ImageMagick 

Via Strategic Board (which I pulled out of my referrer logs - it looks to be another tech blog aggregator) I found Jane Genova on 'Be A Player - Titles Are So 20th Century'. Players never evereverever approach the game as simply the need to earn a living.  It's all about leverage.  I don't accept an assignment in order to pay my rent.  I accept it because I know that I will make the contacts, pick up the skills, and understand the concepts I need to land me the next assignment, at a little higher price that I billed for the last assignment.

I was also amused by The Agile Developer's diagram comparing BizTalk vs WS-* (this was actually via Bill de hÓra not TechTalk, but I figure some TechTalkers might find it amusing anyway).

 

March 04, 2006

Techtalk Highlights 2006-03-04

Interesting stuff I've got from TechTalk in the last 24 hours:

Programming: ramblings of a self taught man sounds pretty familiar. I have actually acquired a little tertiary education but everything I know about programming I taught myself from magazines, books, the net & peers. But Uni did teach me some useful things, like how to work with other people on boring projects. Plus I know what 'turing complete' means, which really impresses  the ladies, l can assure you.

Standard Deviation: building a Ruby Web Spider

Geoff Appleby : What IS Agile?

A CRM Riff.

March 03, 2006

Australian Payment Systems pt 5 - Aggregators

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.

Direct Entry Aggregators

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.

Drilling down on bank account records

TechTalk Highlights 2006-03-03

Secret Geek directed my gaze towards The Looney Bin

The Bit Bucket spelt out What makes a good data entry app

Rory Primrose asked How important is UI design for software?

Australian Payment Systems pt 4 - EFTPOS / CECS

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]

EFTPOS system flow

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.

FedEx Kinko's Payment Card Hacked

(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.

March 02, 2006

The tortoise and the hare

I'm now into month 3 of a slightly over-engineered 12 month bet with my mate Russell (aka Dr Rugby). The fine print is this:

  1. There was an official weighing process on or about Jan 1, 2006.
  2. There will be another official weighing process on or about Jan 1, 2007, followed by a race around the Bay Run. Whoever has lost the most weight as a percentage of their starting weight will receive a head start equal in minutes to the difference in percentage weight lost by myself and russell over the 12 months (i.e. if I lose 5% of my starting weight, and Russell loses 12%, he gets a 7 minute head start).
  3. The penalty for coming last in that race (which is 7km long) is to have to do a second lap immediately.

The last time we went man-to-man on the bay run (about 6 months after an inatentive cabbie made my femur snap) I totally broke his will. So I reckon if I can keep the head start to under 5 minutes I'll break him again. 

Russell's plan appears to be 12 months of no beer and moderate exercise. My plan was to ignore the whole deal till october, then go cold turkey and hit the tarmac for the last 3 months. But now I've found The Couch to 5k running plan (thanks to James Webster) which claims to only need 2 months. Roll on November...

techtalk highlights - 2006-03-02

The best stuff I've seen in the last 24 hours on TechTalk :

JD’s Weblog points at using Google SiteMaps to find out where you rank for search terms you care about. I see I am still a very long way indeed from owning 'jonno'.

Via Piers7 comes a link to In Praise of Code Reviews

Uber Tablet asks if Microsoft's latest buzzword will make google useless for fans of traditional japanese paper-folding?

 

Australian Payment Systems part 3 - RITS

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.

direct deposit system flow

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

March 01, 2006

techtalk highlights - 2006-03-01

Highlights today from TechTalk:

 

Australian Payment Systems

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:

 

Australian Payment Systems - Pt 2 - BECS

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