virtual bank account
late business concept
So why is it still here on our website? Because it remains a good illustration of our approach to business concepts, and of the ideas that are the basis of the veryard projects Business Challenge.
The virtual bank account concept described on this page was intended to represent a new form of added-value - creating a potential new role in the banking market.
The virtual bank account concept developed from an analysis of the inflexibility of existing banking concepts. The development of the virtual bank account concept follows a repeatable pattern of business analysis.
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.
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:
|cheque||standing order||direct debit||virtual bank account|
|making payment||I pay each bill by a separate cheque
payment is totally under my control
high transaction costs (for all parties)
|my bank pays a regular amount to selected creditors
only allows for fixed amounts at fixed perods
I have reduced effort for paying regular bills
creditor gets improved cashflow, and reduced risk of cancellations
|selected creditors take what I owe them directly from
allows for variable amounts or variable payment periods
some companies offer a discount to customers who pay by direct debit
|as direct debit|
|changing bank||I use a new cheque book||I provide a list of standing orders to my new bank||I have to notify dozens of companies that my bank details have changed||I notify my virtual bank of my new bank details.|
|it's easy ...||to change payment amounts and periods
to change bank
|to change bank||to change payment amounts and periods||to change payment amounts and periods
to change bank
|it's difficult ...||??||to change payment amounts and periods||to change bank||??|
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).
It also illustrates the fact that flexibility is two-edged. One man's flexibility may be another man's risk.
|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.
A single direct debit mandate can be regarded as a three-way relationship, involving three roles: payer, payee and bank.
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.
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.
It turns out that this can be decomposed fairly easily into three three-way relationships.
AUTHORIZE DIRECT DEBIT involves payer, payee and virtual bank
EXECUTE DIRECT DEBIT involves payee, real bank and virtual bank
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.
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.
Copyright © 1999 Veryard Projects Ltd