GREEN MONEY
PAYMENT SYSTEM
ANALYSIS OF
POSSIBLE
SOLUTIONS
London, 13 Feb. 2012
bureau@la40.org
Goals:
 To determine whether it is possible to create a
demurrage complementary currency electronic
payment system using core banking software to be
implemented in case of emergency scenario (providing
additional liquidity to the economy in case of credit
crunch);
 To analyse main solutions on the market, define their
functionality, provide details of their architecture and
describe the technology;
 To compare proprietary core banking solutions, open
Scope: UK
nationwide,and
localready
solutionto
foruse
a medium-size
source
solutions
solution town,
based on
reproduced for 100+ locations.
complementary currency.
Core Banking:
 a back-end system that processes daily banking transactions, and posts updates to
accounts and other financial records;
 enables phased, strategic approach intended to allow financial institutions to reduce
costs, improve operations, etc.
 facilitates integration with a financial institution’s existing technologies;
 overall service-oriented-architecture (SOA) helps financial institutions to reduce the risks
that can result from manual data entry and out-of-date information, increases
management information and review, avoids the potential disruption to business caused
by replacing entire systems;
 helps innovate, exceed customer expectations, increase efficiency, reduce operational
costs, and improve customer retention.
Core Banking:
Core Banking Solutions
advantages:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
ease of integration, SOA (Service Oriented
Architecture) and flexibility of aggregation
unified data presentation
multi-currency
multi‐language
multi‐entity
internet banking (Open UI through browser,
HTML and XSLT)
phone banking
maximises re‐use, eliminates silos, duplication,
minimises redundancy and complexity
retail, commercial, wholesale, treasury, private,
corporate banking
mainframe and open technology of a single
source
no end of day
mostly implemented on c++ or java languages
connectivity through XML and Web Services
scalable architecture
straight-through processing (STP)
support for multiple calendars
strong security
disadvantages:
•
•
•
•
•
cost
hardware requirement
excessive reliance on technology
any failure in computer systems can cause
entire network to go down
need in constant update and support
Open Source
Banking Platform
advantages:
•
•
•
•
•
•
•
•
•
•
•
•
open source
free of cost
different channel access: online,
mobile phones, cards, POS (point of sale)
dynamic system configuration (support for
various economic models)
automatic upgrades
connectivity through XML and Web services
implemented on java language
multi-currency
multi‐language
monetary models: Local exchange trading
systems (LETS), Time Banks, Barter,
Complementary Currency, Local Currency,
Factoring
platform independent
demurrage module ready
disadvantages:
•
•
•
•
•
•
•
•
•
new stable releases are issued based on a
principle IIRWIIR (It Is Ready When It Is
Ready)
support through forum
manual installation
project development may be suspended at
any time
the openness of source code may lead to
significant lack of security in future
no in-box scalability
no bug tracking system; bug reports is
tracked on forum; no further action on bugs
repair
code requires thorough review before further
development and exploitation
not tested at the GM emergency scenario
projected scale
iKoruna
advantages:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
ease of integration, SOA (Service Oriented
Architecture) and flexibility of aggregation
multi-currency
multi‐language
multi‐entity
SMS, POS, USSD, bluetooth, ZigBee,
NFC payments
mobile applications and Web UI access
independence from a bank
platform independent
no end of day
implemented on java language
connectivity through XML and Web Services
scalable architecture
strong security
off-line payments: shops, vending, transport
systems
issues own currency for online services and
electronic currency exchanges
cheaper than core banking solutions
disadvantages:
•
•
•
•
•
no loans, deposits, credits
no financial services data model
independence from the bank may lead to future
implications if connection with a bank is needed
the system is closed which would require
developers hiring if some changes or support is
needed
additional scalability tests required
Components of possible total cost
Understanding the total cost of the complementary
currency electronic payment system implementation
requires detailed analysis of an exhaustive list of
functionality as well as the precise scale of users’
transactions and determined security requirements,
which is beyond the scope of this paper. However
important elements which should be considered
include:
• annual maintenance fees or core solution development
costs
Development vs Purchase
Advantages:
Development from the scratch
grants full control over the
system
• It is easy to modify
• Grants compliance with the
architecture
•
Disadvantages:
•
•
•
Significant cost
Needs time (not less then 20-30
months)
Possible errors in development,
scaling or implementation;
Conclusions
 In terms of cost and time it is more reasonable to
purchase and customize a solution instead of
developing it ‘from the scratch’;
 In terms of scalability, security and customer support it
is more sufficient not to use solutions based on the
Open Source code;
 To calculate the total cost of the solution an exhaustive
list of functionality as well as the precise scale of users’
transactions and determined security requirements are
needed.
Recommended further steps
1. Developing a precise Requirements Specification that will
include:

Exhaustive list of required functions;

Security requirements;

Approximate scale of implementation (quantity of users and
transactions).
2. To announce a request for tender using the abovementioned Requirements Specification.
www.ecounit.org
www.teslaconference.com
www.gmwg.org