Bernhard Seefeld's Blog

Electronic Bill Presentment and Payment

In Switzerland, two electronic payment systems for private users will be introduced this year. One is yellowbill by the Swiss Post, which is already online, and the other is paynet, which should be implemented by most major banks by the end of the year. Note, that it was actually possible for most banks (except the Swiss Post's Bank, which handles most offline bill payments) to find a common, neutral standard!

Unfortunately, their design is bloated. I will try to present a much simpler solution.

Both systems work similarly: When you order something and give your address, you can tell companies supporting the system your finance institute belongs to, that you would be prefer to handle the bills electronically. That would not be the same as LSV (Direct Debit), where the amount would be automatically deducted from your account. Rather ticking this option and giving the biller your EBPP-Id will result in all your bills appearing in your online banking application than in your mailbox. That is, of course, you will see them the next time you log in to your virtual bank. (I am not sure yet, wether I find this delayed confrontation with my bills a good thing or not :) ).

In both systems, the actual bill is still stored on the biller's server and not at your bank. This is a good thing, otherwise your bank could learn not only who you buy things from but also exactly what you buy there! Naturally, this implies some mildly complex software at your bank and your biller as you would neither want your bill at a publicly accessible URL (I don't know the details, but I hope nobody is relying on security through obscurity, i.e. supposedly unguessable URLs; probably it will be some sort of signature in the URL and/or a server-to-server communication between your biller and your bank).

This makes clear why the target market for this system are the bigger companies which send many 100'000 bills a month. The overhead to introduce something like this in these companies' internal billing systems and public web sites / services will be huge and complicated. OTOH these are also the companies which have the biggest saving opportunities.

If the users will actually start using this in big numbers, that is.

User conversion! Of all the companies that plan to use yellowbill I have a billing relation with exactly one. I seriously doubt that many people will go through the paperwork to sign up in either of these systems and will actually remember their IDs on their next orders, if most of their bills will still come the old way anyhow. And it wouldn't be like there are any signs, that this ratio would change very quickly soon: This system is only targeted at big companies. And most of my bills come from smaller companies or even small societies. You know, the companies where there had to be someone, who actually put the bill in the envelope by hand! It's the chicken and egg problem, only magnified.

I fear that these EBPP systems will spread very slowly only, because of a Big Problems Call For Big Solutions situation. Of course getting all the banks to agree on a standard was a big effort, so the system implementing ought to be similarly big and encompassing.

Now then, big words you say! What do I propose, you ask?

E-Mail

OK, you probably didn't fall from your chair because of this one. But think about it. What replaced a lot of traditional paper mail? E-Mail! Everybody understands this: "Would you prefer to get your bills by E-Mail?" I would want it! How do I get my bill presented. Not my bank's design decision! This will depend on the capabilities of the biller: My local astronomy society will be happy to remind of the reason in ASCII in the mail. Others might want to attach a pdf. Others (like many online shops) already have an online "past orders" system which can be easily reused here. There are so many useful things I can do with emails: I can print them, I can archive them and I can even forward them (as, luckily, I don't have to pay all the bills I get). And I already know how to do that.

That was the easy part; how about the billing information? This would be four units of information: The account number, the reference code, the due date and the amount. The first two have codes (checksums), the third one comes in a few standard formats and the last one is often prepended by the currency symbol or ends with ".-" or ".x0". It wouldn't be too difficult to add a "paste the payment part of your bill here and I will try to figure out what I have to do" field in the current online banking applications. OK, granted, this one needs a little learning and tad of confidence from the user but it is still much simpler than signing up in either of the above mentioned systems. An alternative would be to forward the relevant parts of the mail to your bank (which you could tell to either directly pay the bill, but that would require some sort of sender authentification or that the bill should appear in your next banking session).

And there is another way (a little more complex, a little more integrated): Create a simple file format with its own suffix and mime type, let your banking application register for this suffix and mime type and then you can attach payment information in your emails. Double-Clicking this attachment will add the bill to your next banking session (no need to login now, just note it). Or you drag'n'drop it to your running banking sessions. Creating this attachments is a matter of simple tools, which can even be web based.

So, this version won't get you down to three clicks to pay your bills (as advertised by yellowbill), but almost. Much more important is that everyone can issue electronic bills like that. Many people even do something very similar already ("Hey, remember when we bought that gift for Steve together, you still owe me your part..." including account number and amount).

A very low tech solution that implements only its own part. Completely open, simple to integrate, simple to extend, very useful.

Why do I write it up? I had the opportunity to plug this concept to one of the usability guys involved in one of those projects. Maybe this blog entry will serve to support this idea.