The Mobile Open Service Model -MOSM- is a streamlined composite scheme aimed at describing the different components of the Mobile Services Value Chain. To achieve this grand objective, the OSM assign each of these components to Layers. The layered structure count for devising a Macro Model which, abstracts the complex reality surrounding any Mobile Initiative and allow the audience to sift thru all the processes, virtual, physical components and concepts.
1. RESOLVING THE EQUATION OF MOBILE FINANCIAL SERVICES…
The Open Service Model is a streamlined composite scheme aimed at describing the
different components of the Mobile Services Value Chain. To achieve this grand
objective, the OSM assign each of these components to Layers. The layered structure
count for devising a Macro Mode which, abstracts the complex reality surrounding any
Mobile Initiative and allow the audience to sift thru all the processes, virtual, physical
components and concepts.
2. This section will present a brief introduction on the issues and themes that aroused the IFSA Global
Payments Conference as point of view of the author. To be a bit more specific:
1. What is the “point” of the author regarding the Mobile Banking Services?
2. The author has countered the arguments presented by the speakers, not because they were wrong but,
because they were certain: Mobile Banking Services seems to be a difficult market because it requires such
a “Collaboration” approach that we are confronted with the facts that there might not be enough experience
on the needed models.
3. The author also commented on “Contextual Displacement”, “Full Paradigm Shift” and everybody needing a
new “perspective” to look into the matter and find a solution to the problems using current solutions.
4. The sheer size of the market should really motivate us to deal with the challenges TODAY and not WAIT until
“tomorrow”. There 1.5 billion internet Users in the world but there are 3.5 billion Mobile Phone Users.
5. I don’t share the “wait-and-see” strategic posture brought up to us by the Speakers: This is my proposal.
What to expect?
3. The context (1)
I was an attendee at the IFSA Global Payments Conference which took
place at the Sheraton New York in March 2008.
I am currently partaking a Mobile Banking Services Innovation Forum at my
current Employer.
I selected the IFSA Global Payments Conference because I foresaw the
planned content would go along with my current line of work.
While at the conference, I noticed content was dealing more with entry
barriers and current internal US market issues than with current successful
models and possible solutions to the issues.
Most of the speakers aimed at presenting Market Survey Results based on
perceptions of users who, probably, would not know too much about the
subject anyway.
The market studies portrayed a very “Negative Outlook” for Mobile
Services Banking and payments.
4. The context (2)
During the breaks I made comments to Nick Holland, Paul Mangieri and
others about the following issues:
A Paradigm shift is needed to approach the Mobile Banking Services.
A Contextual Displacement was necessary.
Innovation is not possible with an Inside-out perspective.
You need to abstract yourself and think on the solution at a higher level.
Stop calling the I-Phone a “Phone”: That to me is like calling it a “Morse-Code
device”
During the sessions I came up with a “alternative way” to call these innovative
devices.
5. The context (3)
I made a “sort of” commitment to those a I mentioned my “ideas” in these terms:
I will strive to concoct a “Minimalist Model”: Based upon the so-called
Contextual Displacement.
Beginning by looking at Mobile Phones as JUST NEW gadgets to access the same
applications we already know.
I will elaborate on these arguments a few slides ahead.
While looking into the issues aroused by my own comments I have run agog because to my
dismay: The industry is heading, precisely, forward to the direction of my initial proposal.
First, the industry Leaders, like Apple, Intel, DoCoMo, Google are working to make the
Mobile Phone a Universal Mobile Device with an standard secure platform.
Second, but not last, it adds up to the point I argued that we should demote the “phone”,
if not in features, at leas in the appreciation and attention it gets. A phone is not a Phone
Any more (see the I-phone web site).
Third, it is very important to deal with the solution from a conceptual and abstract
viewpoint. Otherwise, we might run into problems by taking every sheep to the wolf, as
we do by dealing with the trees and not mapping the whole forest.
6. This section will present the proposed solution to the Mobile Services Puzzle. Some of the questions
that would be answered by this model:
1. What is the Open Service Model and how does it might work out a solution to counter the
“Negative Outlook” discovered by the Market Surveys?
2. Is it possible to set up a viable Business Case for the Mobile Banking and Payment Services
Stakeholders?
3. Who are the stake holders and What roles should they be entitled to play?
4. What roles should each one of them play on the final solution?
5. No dough, No go! Where are the new revenue streams for the participants involved?
6. How to deal with Security on Mobile Devices?
7. Is there any way we could go through with implementation using current technologies and
current solutions to the market issues presented by the IFSA Conference?
Open Service Model
9. Open Service Model (1)
Stop Calling the I-Phone a Phone:
By calling the I-Phone a Phone you are locking yourself out of new
potential applications.
Reminiscence of a Morse-Code pointer, the original phone concept is totally grounded on “wired”
communications and limited features devices.
Think of what you really do with a phone: You pick the handset, dial a number and then Talk. And that’s
it! That’s a Phone.
So let’s start off this discussion by not calling the I-Phone a Phone or, at least, not constraining it to Just
That.
I will suggest everybody call the I-Phone and any device with similar features a Portable (or
Mobile) Internet Device (PID o MID), meaning a window to the network thru which you are
able to interact using an intuitive interface and a bunch of flexible applications hosted by the device.
I think the Phone was finally superseded by this new device. Heretofore, devices will be more user
friendly, hosted applications and original phone functions will be blended smoothly into an ergonomic,
intuitively-operated front-end, encased on a sheer stylist design.
But while PIDs are very interesting let’s deprive them of such high esteem and just categorize any phone
as a “Device” (PID).
As far as this work is concerned , PIDs concept will be restricted to “devices” capable of performing
according to the Open Secure Terminal Architecture, I Phone 2.0, or the Google android
Specifications, teeming with current Handset Operating system capable of running high-end
applications.
10. Open Service Model (2)
By displacing the context, let’s devolve the phone to what
it really is:
Dispossessing the phone of such a high-ranking position will really allow us to rethink a
new “Collaboration Model”
By downgrading the phone to a “device” it becomes more readily to conceive a new
framework or specifications based upon interoperability and co-existence of the diverse
components of Mobile Banking Services.
In fact, dealing with a phone is very similar to dealing with
Printer: What gets it all tangled is when you give this user interaction device the status
of “Main component” on the Value Chain.
If PRINTERs were to receive such a “treat” of consideration, we would still be
thinking of which way should the tasks related to “PRINTING” be assigned to each
stakeholder.
As we are fully aware of: Industry really hit the nail on the head by leaving the problem
where it was pertinent to solve: The Printer Manufacturer is the one charged with the
solution of the “Driver” and Printing Requirements are just clearly stated
in the OS Specifications and the expectations of the future customers.
What happens if a printer does not comply with the scheme? Well, let me put it this way:
The device would NOT BE A PRINTER at all.
11. Open Service Model (3)
The Open Service Model:
The OSM is a High Level Architectural Framework.
It is an Intend to underpin standardization to Mobile Banking Platforms.
The OSM is not a FINAL SOLUTION, just a BRIDGE to It.
There are SIX LAYERS on the Open Service Model.
It states how you SHOULD THINK about THE SOLUTION.
The SOLUTION boils down to designing new SPECIFICATIONS beyond the Mobile
Device to blend smoothly the Payments Infrastructure with the Banking Processes and
Mobile Network operations on clear-cut and streamlined Value Chain.
Read it from left to Right and you get an immediate clear picture of the relationships.
12. Open Service Model (4)
The Customers Layer:
The Customer Layer is the first Layer the Left.
It represents the different constituencies of users that might be interested on the Service Offers of the
Value Chain Participants.
Customers represents Markets.
Customers or Markets only exists if there Value Added Services to be offered to them.
On the outset it must be understood that these markets, in fact, are further divided into Niche and
segments. Not all products will have appeal to all sorts of customers.
Device Layer:
The Device Layer is the second from left.
The Device Layer stands for ANY DEVICE that fits the previous MID/PID concept.
It “demotes” the Phone from its high-ranking position on the Mobile Services Model.
Notwithstanding, the MID continues to hold a relevant position.
It means you will need to handle EACH DEVICE independently.
It does not matter the TYPE of DEVICE: It Matters that you MUST HAVE a DRIVER for IT.
What should be clear-cut are the SPECIFICATIONS of the PROCESS to be HANDLED.
A MID would be either “Standard” or “Non-standard” depending on its capabilities to operate under one of the
standard OS.
13. Open Service Model (5)
The Device Management Layer:
The Device Management Layer is third from Left.
The Device Management layer defines requirements for specifications to handle devices
independently.
For EACH device you should build a DEVICE HANDLER or CONNECTOR.
These CONNECTORS should not deal with content.
They are middleware to connect the Value Chain Layer Services with the Front-End Devices.
The main objective is to be able to build a Matrix Specifications that will allow to re-compose the
Market Offers in terms of:
An asynchronic bunch of SERVICES to be offered.
Running on as many devices as possible.
As long as they have DEVICE MANAGER available for the SERVICE on the specific DEVICE.
It all comes down to the Device Manufacturer providing the Device Handler for the Business
Network Operating System.
As simple as providing a DRIVER for a PRINTER on a Windows OS Environment.
The following initiatives go along the same lines:
Open Secure Terminal Architecture (OSTI): Specifications in a collaboration effort between INTEL and DoCoMo.
IPHONE 2.0: An interesting Device Handler that encompasses a Platform Development Kit as well.
Google Android: A very interesting initiative which prescribes all sorts of MIDs for a diverse range of applications. See Goodle
Dream Phone (Search for images in Google).
14. Open Service Model (6)
The Distribution Channel Layer:
The Distribution Channel Layer is fourth from Left.
This layer is entitled to separate attributes pertinent to the Channel.
It is just a REMAINDER of the specificities of channels.
It also contributes to the “Contextual Displacement” concept.
To catch the Concept: Just bear in mind which channel you are dealing with whenever
you are constructing a SERVICE SPECIFICATION.
To be honest: Since we are focusing on MOBILE SERVICES, the channel have little or
not relevance, barring the fact that certain services run directly over the Wireless
Network and other use the network to send standard HTML pages, which means
internet over a Mobile Network.
Just to clear it up: You will find to different channels on the Model. Internet and the
Wireless Network. Internet would be, catch, running over the Wireless network too.
15. Open Service Model (7)
The Value Chain Layer:
The Value Chain Layer is fifth from Left.
As we have seen Industry is leapfrogging in the “Device Management” issues.
Consider OSTI, IPHONE 2.0 and Google Android as frontrunners of this trend.
We need the same sort of effort to work out at the Value Chain Layer.
This is a very important Layer where most of the Following statements should be
clarified
Which Business Models are to be included in the Final Specifications.
This work imust be followed by Streamlined Opern Services Model Specificatons which will work
out all aspects regariding the roles, responsibilities, relationships and compensation of the
differenta actors .
The chosen Business Models iwill probably define these relationships.
The Payments Infrastructure, e-money storage management, revenue distribution, princing, clearing,
settlement, risk management, prudential regulation and the transfer of value from scriptural money
in a bank account to the e-money management institutions, among other imporant issues.
16. Open Service Model (8)
The Value Chain Layer:
The Value Chain Layer is fifth from Left.
This layers describe the PARTICIPANTS: Platform Operators, Service (content)
Providers, Mobile Operators, ancillary and supplementary services suppliers.
All tied by the Value Chain and constrained by the standard definitions contained in the
Open Service Model Specifications.
BANKS are also INCLUDED: The bank is represents the link between the outer world
and inner world. Trespassing its frontiers in one direction means e-money becomes
scriptural money and reversing the course means Scriptura Money becomes e-money.
Value Chain is also meant to separate Financial and Physical Value Chain Processes.
The MAIN OBJECTIVE of the Value Chain Layer is to define the ATTRIBUTES of a Commercial
Transaction in terms of a Process spanning across Participants Boundary.
Value Chain Members define ATTRIBUTES for TRANSACTIONs to take place according to the ROLES
they are ENTITLED to play according to the OSM SPECIFICATIONS.
Because INDUSTRY is on the right track with regards to Platform standardization on the Handset the
Value Chain Layer becomes A+ priority for Specification.
On Standards: Current status is at least four Market Leaders are involved in 3 different standards for
the handset, and there several operating systems in use nowadays, to boot.
17. Open Service Model (9)
The Payments Layer:
The Payment Layer is sixth from Left.
The Payment Layer Specifications should deal with how Credits and Debits, tallying with
economic value, are transferred between the Participants.
E-Money(*) definition:
An e-value which represents a monetary value (real scriptural money)
Stored in Electronic Device.
Issued on receipt of funds of an amount not less in valur then the monetary
value issued (funds might be exchange at a later specified time/date).
Accepted as a means of payments by undertakings other than the issuer.
An example will help to fathom this concept: Take pre-paid cards
issued by Mobile Operators:
Pre-Paid cards that are used solely in exchange of “airtime” should be
regarded as Stored Value Cards.
Pre-paid cards which might be used to pay for goods offered by merchants
(different to the issuer) will be considered as e-Money.
18. Open Service Model (10)
The Payments Layer:
The Payment Layer is sixth from Left.
The Payment Layer Specifications should deal with how Credits and Debits, tallying
with economic value, are transferred between the Participants.
It defines the Circulation of e-Money and how it comes in and goes out of the
Network.
When e-Money comes in: Legal Tender or Scriptural Money is transferred from a
bank account, or issued in receipt of funds (by an agent office, for example) into the
Network with a value not less than the monetary value received or taken from the
account.
When e-Money goes out: E-value (content of an e-wallet, a SIM, or multi-purpose
Prepaid Card) is transferred back into a Bank Account or redeemed into cash in
exchange.
This is a very useful “Context” upon which we might be able to conceive a heck of
new services by liberating us from the constraint of the technology, the device or the
Payment Instrument itself.
19. Open Service Model (11)
The Payments Layer(cont.):
Payment Layer defines also Payment Finality: By-laws accepted by Customers and
Value Chain members alike, to which everybody acknowledge to be bound upon
initiating a OSM compliant transaction.
Finality, in this context, also describes the processes thru which different members of
the Value Chain would execute “Transfer of Value” among themselves in terms of
Clear-Cut Clearing and Settlement Processes built into the Open Service Model
Specification.
OSM will also deal with the Settlement Risks arising from the Clearing and
Settlement Processes necessary to effect the “transfer of value’.
Compliance will be part of this Layer too: OSM Specifications will deal with all
requirements from the onset, to assure pertinent authorities E-Money will not be the
source of new Money Laundering and illicit activities financing.
20. Open Service Model (12)
Prudential Risk Management (*)
The e-Money issuance by Mobile Operators or Platform Operators might generate
some risks:
Risks stemming from the Insolvency of the e-Money Institution (Issuer).
Risks stemming from the lack of liquidity to satisfy redemption requests.
Financial Stability Risks associated with the loss of confidence in this means of payment.
Prudential regulation might be needed only for the specific segment of
activity linked to the issuance of e-money.
21. Open Service Model (13)
Payments Instruments for the Mobile Transactions(*)
Around the world several instruments have been used as payment means.
Not all payment means are considered e-Money.
The most commonly used in Europe:
Credit Cards.
Debit Cards.
Debit to the Phone Bill.
Pre-paid Cards – Airtime only.
Pre-paid Cards – Multi-Purpose (e-Money Card).
OSM includes a “Virtual Loading or Unloading” of an e-Wallet with e-
Money.