virtual bank account

---

One way of achieving flexibility is through a mechanism known to computer scientists as indirect addressing. Best explained through some examples.
 

	On the Internet, I can set up an email alias, for example through bigfoot.com. If I change ISP, I merely need to alter the redirection rule - I don't have to notify all my friends and associates.
	Even the old postal system has the notion of box number. Only the postman needs to know where I actually live. As long as I keep the same box number when I move house, I can still receive all my mail.
	Some telephone companies now offer a phone number for life. Anyone who dials this number will be automatically redirected to your current mobile phone.
	(Some telephone regulators are demanding that telephone companies allow customers to keep their telephone numbers when they switch from one company to a competitor. From the customer perspective, this a different solution to the same requirement. However, from the telephone company's perspective, similar mechanisms may be involved.)

Let's look at another area where this kind of flexibility might be desired - personal banking.

If I want to move my account from one bank to another, it's a mess. Lots of my regular bills are paid by direct debit, which means that the money is automatically withdrawn from my account. And I receive some dividends and other payments directly into my bank account. My bank account number is stored on dozens of computer systems, perhaps even hundreds, and if I want to change my bank account I've got to notify everyone. It's very inconvenient, so I'm not going to change bank very often. Perhaps that's the way the banks like it.

When I've discussed this example, some people have said that all I need to do is close the account, and wait for everyone to complain. But this merely delays the inconvenience. And if I have direct credits as well as direct debits, I might be less willing to adopt this solution.

The virtual bank account contains no money. It merely contains a pointer to your real bank account. Instead of giving your real bank details to lots of utility companies and others, you give them your virtual bank details. Then when their computers generate a transaction, such as a direct debit, this transaction will be automatically redirected to your real bank account.

Once we've grasped a basic business concept, then we can start to explore the practical questions in detail:

• how is this actually going to work?
• who is going to pay for it?
• how are transactions going to be executed and verified?
• what are the possible failure modes?
• how is this system guarded against error or fraud? ...

Standing orders are less flexible than individual cheques, but may be more convenient for certain classes of payment, because the transaction costs are lower. Many companies prefer to be paid by standing order, because it reduces the risk of cancellation (for example, magazine subscriptions).

This illustrates that there is a trade-off between flexibility and other factors, such as transaction costs.

It also illustrates the fact that flexibility is two-edged. One man's flexibility may be another man's risk.

When analysing flexibility, we have to ask: flexibility for whom, in what context?

	Some of the objections will be short-term - perhaps in terms of security and fraud, current banking regulations, cashflow or whatever.
	Some of the objections will be longer-term - is this scaleable and sustainable over time?

To identify and address these objections seriously and systematically, we need creative thinking within a structured methodical framework.

Modelling direct debit

A single direct debit mandate can be regarded as a three-way relationship, involving three roles: payer, payee and bank.

(Some modelling pundits claim that three-way relationships must always be decomposed into a set of two-way relationships. This example shows why I disagree.)

Let us suppose I wish to write a computer system to handle my domestic accounts. One of my requirements is to check the consistency between the gas bill and my bank statement. I specify this requirement by reference to the rules governing the three-way interaction known as direct debit.

Decompose into two-way interactions?

Furthermore, my viewpoint on the direct debit situation hides several other agents, who might be visible from the viewpoint of the bank or the gas supply company. Perhaps the gas supply company holds its accounts with a different bank. Perhaps the direct debit transaction is passed via some clearing system. All of this is irrelevant to me.

In other words, although an omniscient requirements engineer might be in a position to work out the full interaction between all the parties, this is not necessary or relevant to solving my problem. In more complex cases, it may be impossible for anyone to have the complete picture.

Of course, two-way interactions are easier to implement than three-way interactions, for a variety of reasons. But that isn't a good enough reason to force all interactions to be expressed as two-way interactions at the requirements stage.

My position here is based on three key methodological principles:
 

	I want to be able to express requirements based on partial information, or based on a particular user viewpoint. And I want to be able to test particular solutions against such requirements. I don't want a method that assumes I've got a complete picture of a closed system.
	I want a notation that is as permissive as possible. I may then want to provide design guidelines warning designers that the full complexity and power of the notation is not currently supported by available tools and techniques. I don't want a notation that is unduly limited by current tools and techniques.
	There are often several different ways of decomposing a three-way interaction into a set of two-way interactions. I see this as a design choice - several solutions to the same business requirement. Although I recognize that I cannot eliminate all design choices from the statement of requirements, I don't want to have more than I can help.

In other words, I don't want a requirements or design method that forces me to decompose three-way interactions, any more than I want a data modelling method that forces me to decompose many-to-many relationships. What I do want is a design method that helps me to implement such structures by converting them into more manageable structures, at the appropriate stage of the design process.

Modelling virtual bank account

It turns out that this can be decomposed fairly easily into three three-way relationships.

ESTABLISH VIRTUAL BANK involves payer, virtual bank and real bank

AUTHORIZE DIRECT DEBIT involves payer, payee and virtual bank

EXECUTE DIRECT DEBIT involves payee, real bank and virtual bank

Who pays for the service, and when?

A bank might offer this service free as a short-term tactic for taking customers away from other banks. But this might not be sustainable in the longer term.

A separate commercial entity might charge a joining fee to consumers. I can imagine being willing to pay a reasonable fee to a bona fide company or agent, in return for providing me with this and perhaps other related services.

Is there a natural limit to the size of the market?

If people get used to a single service, they may start to think of reasons why they want several differentiated services. Perhaps someone wants one virtual bank account for dealing in stocks and shares, and another for domestic bills. The particular reasons are likely to be many and varied, and we don't have to anticipate them in detail. But we should anticipate the trend: unlimited growth.

veryard projects can help identify, analyse and model business scenarios, opportunities and threats.

top home page contact us
	This page last updated on November 12th, 1999  Copyright © 1999 Veryard Projects Ltd  http://www.veryard.com/business/soddit.htm