WO2019008343A2

WO2019008343A2 - A computer-implemented system that enables the deployment of configurable and customizable financial services

Info

Publication number: WO2019008343A2
Application number: PCT/GB2018/051866
Authority: WO
Inventors: David POULTON; Soumaya HAMZAOUI
Original assignee: Redcloud Ip Limited
Priority date: 2017-07-03
Filing date: 2018-07-03
Publication date: 2019-01-10
Also published as: GB201710600D0; WO2019008343A3

Abstract

The invention is a computer-implemented system that enables the deployment of configurable and customizable financial services. The system includes: a transaction processing sub-system; a data store that stores a flexible entity model, which is a hierarchical model that represents the different multiple actors which the system needs to be used by, and the relationships between the different multiple actors; and an interface between the flexible entity model data store and the transaction processing sub-system. The transaction processing sub-system is accessible by any new entity that is configured to conform to the flexible entity model and that is also configured to exchange data over the interface.

Description

A COMPUTER-IMPLEMENTED SYSTEM THAT ENABLES THE DEPLOYMENT OF CONFIGURABLE AND CUSTOMIZABLE FINANCIAL SERVICES BACKGROUND OF THE INVENTION

1. Field of the Invention

The field of the invention relates to a computer-implemented system that enables the deployment of configurable and customizable financial services.

A portion of the disclosure of this patent document contains material, which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

2. Background of the Invention Existing banking ecosystems use opaque cash payments which cause inconvenience as they often are time-consuming, a safety risk and expensive to operate, as illustrated by Figure 1. In addition, existing ecosystems do not allow everyone to have access to bank services— the so-called unbanked'. As an example, at the bank level, no identification or credit history will result in a denied access to a bank and its service. There are estimated to be 2 billion unbanked persons in the world

An emerging solution providing a larger number of services in particular for the unbanked is agency banking. Agency banking allows retail networks or commercial entity to act as banking agent, enabling a larger number of the population to access financial services through the agents.

However, existing core banking systems cannot readily enable agency services, as they are often inflexible and not easily configurable. Existing core banking systems are also unbanked unfriendly and regulator unfriendly when integrated with closed mobile payment systems like M-PESA.

Another growing financial service is merchant payment service, which allows merchants to enable transactions through for example credit cards, debit cards, or mobile payments.

There is a need for a configurable platform that would be able to offer a wider range of services to existing customers as well as being able to reach out to new customers, while at the same time being able to directly integrate to existing core banking systems. The present invention addresses the above vulnerabilities and also other problems not described above.

SUMMARY OF THE INVENTION

The invention is a computer-implemented system that enables the deployment of configurable and customizable financial services, the system including: a transaction processing sub-system; a data store that stores a flexible entity model, which is a hierarchical model that represents the different multiple actors which the system needs to be used by, and the relationships between the different multiple actors; and an interface between the flexible entity model data store and the transaction processing sub-system; and in which the transaction processing sub-system is accessible by any new entity that is configured to conform to the flexible entity model and that is also configured to exchange data over the interface.

BRIEF DESCRIPTION OF THE FIGURES

Aspects of the invention will now be described, by way of example(s), with reference to the following Figures:

Figure 1 shows a diagram schematically illustrating existing core banking system

(Prior art) .

Figure 2 shows a diagram schematically illustrating existing core banking system

(Prior art) .

Figure 3 shows a diagram illustrating the digital financial services of the RedCloud

One platform, which is an implementation of this invention.

Figure 4 shows an example of connected devices that provide access to the

RedCloud One platform.

Figure 5 shows a diagram illustrating the agency banking system.

Figure 6 shows a diagram illustrating a business banking system.

Figure 7 shows a diagram illustrating a business banking system.

Figure 8 shows a diagram illustrating a personal banking system.

Figure 9 shows a diagram illustrating the RedCloud One platform.

Figure 10 shows a diagram of the RedCloud One platform accounting model.

Figure 11 shows a diagram illustrating RedCloud's smart integration module.

Figure 12 shows a diagram illustrating RedCloud's integration with 3^rd parties.

Figure 13 shows a screenshot of the RedCloud One Administration web-portal.

Figure 14 shows an example of myRedCloud, a task-oriented browser-based configuration tool.

Figure 15 shows an example of an agent app.

Figure 16 shows an example of a merchant app.

Figure 17 shows an example of a consumer app.

Figure 18A shows an example of a smartphone interface.

Figure 18B shows an example of a smartphone interface.

Figure 18C shows an example of a smartphone interface.

Figure 18D shows an example of a smartphone interface.

Figure 19A shows an example of a smartphone interface.

Figure 19B shows an example of a smartphone interface.

Figure 19C shows an example of a smartphone interface. Figure 19D shows an example of a smartphone interface.

Figure 20 shows a graph of the kind of profile that can be configured.

Figure 21 shows a diagram representing the general interaction within the platform for processing of client initiated financial transactions.

Figure 22 shows a diagram of the system architecture of the RedCloud One platform.

Figure 23 is a diagram showing the process of cache filtering of requests through various servers.

Figure 24 shows a system diagram of the RedCloud One platform.

Figure 25 shows an example with three deployment structures.

Figure 26 shows a diagram the core of the entity model implementation through database tables.

Figure 27 shows a diagram illustrating the merchant/SME eco system.

Figure 28 shows a diagram illustrating the merchant/SME eco system and highlighting the business-to-business (B2B) key features.

Figure 29 shows a diagram representing the B2B key features.

Figure 30 shows a diagram representing the platform monitoring and controls. Figure 31 shows a diagram incorporating a 3^rd party distribution service digital account platform.

Figure 32 shows another diagram illustrating a merchant/SME eco system and highlighting the consumer-to-business (C2B) key features.

Figure 33 shows another diagram representing the consumer-to-business (C2B) key features.

Figure 34 shows a diagram representing the full merchant cloud features.

Figure 35 shows a diagram illustrating a merchant/SME eco system and highlighting the loans/micro credit key features.

Figure 36 shows a diagram representing the loan/micro credit to merchant features. Figure 37 shows another diagram illustrating a merchant/SME eco system and highlighting the business-to-government (B2G) key features.

Figure 38 shows a diagram representing the B2G key features.

Figure 39 shows a case study example.

Figure 40 shows a case study example. DETAILED DESCRIPTION

This Detailed Description section describes one implementation of the invention, called the RedCloud One platform. The RedCloud One platform includes a transaction processing sub-system.

Key features of the RedCloud One platform include one or more of the following:

Open configuration and customisation at low cost:

· Configurable data repository: 350+ tables defining optimal re -usable components— enables fast, reliable and low cost roll out of new services.

• Configuration performance: the system holds configuration data in an optimal structure both in memory and in the database to allow efficient processing of transactions.

· Configuration autogeneration: the system provides tools that ease the creation of the configuration data and enforces rules that prevent incorrect configuration being installed. This is quite a significant undertaking in a system with, such a large number of configuration tables.

• Flexible entity model— enables any and all actors to be modeled and incorporated (e.g. agents, super-agents, customers, places, e-commerce companies, regulators, insurers etc.) and incentivization models built for each - enables rapid, low cost roll out of different services for different segments, but all with a shared underlying architecture.

• Simple form-based UX for customers and agents — enables rapid, low cost roll out of different services for different segments, but all with a shared underlying architecture to give a simple, fast, low cost roll-out model. This is achieved by configuration and generation of the User Interface, including menu items and prompts. This, for example allows the same services to be offered to different channels.

· Dynamic, extensible plugin based workflow— enables rapid, low cost roll out of different services for different segments, but all with a shared underlying architecture. This allows workflows to be reused to prevent hard coding of the system. System designed for agency services:

• Moves agency commission management to the edge, outside of core banking, in a modular system architected for simplicity and flexibility. The charging structure in the system allows for different business models to be implemented by users of the system.

• Places agency commission calculation functionality at its heart: enables efficient and successful business models emphasizing central role of agency payments.

• Dynamic, real-time updateable agency management— e.g. paying commissions and other incentives immediately, with instant update of rates etc. for maximum market responsiveness.

• Simple form-based UX for agents: enables new services to be rolled out with no mobile phone or device integration complexity for agents; and no need to customers to have mobile phones (agents merely need to reliably ID a customer).

• Integration with existing agents networks: Such as petrol station chains, giving agents access to a vast new range of services to sell.

System designed for the unbanked:

· Shadow accounts processed centrally: enable agents to provide services to the unbanked even without mobile phones; agents merely need to reliably ID a customer; shadow accounts track all events, and commissions and charges. Shadow accounts update accounts in the core banking system in real-time.

^• Access to insurance services via agents, tracked using shadow accounts.

· Access to e-commerce services via agents, tracked using shadow accounts.

^• Access to health services via agents, tracked using shadow accounts.

^• Access to education services via agents, tracked using shadow accounts.

^• Simple form-based UX (for customers with mobile phones): enables rapid, low cost roll out of different services to mobile phone equipped customers for different segments to customers, with no device integration complexity or core banking integration System is regulatory transparent (i.e. a banking or financial services regulator is given full transparency):

· Shadow accounts processed centrally and update accounts in the core banking system in real-time: gives full regulatory transparency, unlike closed mobile phone based systems;

• Flexible entity model: enables rapid, low cost compliance with changes to the regulatory or central bank environment.

The RedCloud One platform provides the following main advantages:

• the system is completely configurable and at low cost;

• the system is designed for agency services to be agent friendly;

• the system is designed for the unbanked, even those without mobile phones;

· the system provides regulatory transparency; and rapidly and cheaply adapts to new regulatory or central bank requirements;

• the system is designed for merchant payment services to be merchant friendly.

The RedCloud One platform supports the following:

· regulatory approval

o adaptable to technology and to local requirements;

• best practices

o local partner and experience;

• products covering various customer segments

o P2P, B2B, B2C, G2P

o Microsaving/loans

o Bill payment

• end to end technology solution

o applications;

o open integration modules:

o business intelligence;

o transactions powering;

o infrastructure. Any one or more of the features listed above may be applied to agency banking services and/ or merchant payment services and/ or digital account based system. 3^rd party delivery service:

Another feature of the RedCloud One platform is itegration with a 3^rd party delivery service in the context of agency banking:

• Integration of a delivery management system with the RedCloud One platform.

• For example: The 3^rd party service may partner with a bank, which may ask the bank for a new delivery point. The 3^rd party service is able to work with an agent that has been identified by the bank, in order to get their goods paid for and delivered at the agent.

• This, in turns, leads to a number of new opportunities:

o Agents are able to develop their portfolio of services;

o Banks are able to reach out to a larger number of customers and deliver more services.

Online shopping for the unbanked

In emerging markets, where credit cards are not always available or a large number of the population is unbanked, the RedCloud One platform and technologies may be used to provide an unbanked consumer the ability to make an online purchase. When an unbanked consumer makes an online purchase, a unique reference number will be issued back to the consumer. The consumer may then pay by cash at a merchant, which will be able to validate the transaction, using the unique reference number.

1. Introduction

1.1 Overview Figure 2 shows a diagram schematically illustrating existing fragmented core banking ecosystem in which not everybody has access to a bank.

In comparison, Figure 3 shows a diagram illustrating an example of the digital financial services of the RedCloud One platform. RedCloud Technology provides solutions to enable financial service providers to deliver digital financial services to anyone, anywhere, using any connected device, as shown in Figure 4. The platform is available on the Public Cloud, Private Cloud and On Premise. It is a collection of end-user web-based services, complemented by an administrative web application. It supports a broad range of financial transaction types delivered by RedCloud's customer (the Money Transfer Organisation - MTO - who license the software) and a range of end users, including consumers, merchants, SMEs, agents and field officers.

RedCloud provides a marketplace solution providing software and financial services to a wide number of participants or entities, such as manufacturer, distributor, merchant, bank, retail group or any FMCG (Fast Moving Consumer Goods) company, consumer, technology vendor, telecom operator, government institution, savings and loan company or insurance company. The flexible entity model enables all participants and their relationships to be modeled within the same underlying digital payment infrastructure.

By creating a new connected digital ecosystem, the marketplace offers a fully integrated and fair financial system for all participants, dramatically reducing costs for financial services providers and transforming the way in which manufacturers, distributors, merchants and users transact locally and globally. The marketplace or platform has a number of products to select from:

• Financial Services Cloud:

o RedCloud's flagship product containing all features and functions of the platform; o End-user stored-value accounts;

o Transaction types including all payments, savings, loans and insurance

functionality;

o Full breadth of available end-user channels, including web, USSD, STK and App;

o An advanced Analytics suite.

The platforms act as specific solutions built for the needs of agent networks service providers:

• Agent Cloud

o Transactions Activity;

o Liquidity Management;

o Business Intelligence;

o Field Management.

Figure 5 shows a diagram illustrating the agency banking system, where local retailers act as bank branches/ATM and perform banking services to extend the reach of the bank in a cost effective way. The only cash transaction left is between the local retailer and the bank. Figure 6 shows a diagram illustrating a business banking system, where businesses and institutions may receive digital payments instantly from SMEs and individuals may buy goods and services from them.

Figure 7 shows a diagram illustrating a business banking system empowering supply chain partners, where consumers and SMEs may make digital payments from their wallet to the distributor's wallet, instantly triggering a notification confirming the payment received. Hence, financial operations and customer management are optimized. Figure 8 shows a diagram illustrating a personal banking system providing advanced experience and consumer insights. Consumers may have access to rich financial services on their mobile device for a better user experience. Leveraging the social effect, they are at the centre of the ecosystem.

1.2 Customers

RedCloud's platform is available to a broad range of financial service providers including, but not limited to, the following: banks, agent networks and/ or fintech organisations. The platform enables banks to:

• Acquire market share through launching new digital services;

• Extend the range of financial services offered by launching new services;

• Deploy branchless banking strategies and serve new customer segments including those currently using third party agent networks;

· Benefit from additional revenue streams;

• Provide remote access for customers via any channel (smartphone, feature phone, web, ATM);

• Use dashboards and reports.

The platform enables agents to:

• Earn commission via new customer registrations and transaction facilitation;

• Increase customer reach through geolocation features and online chat services;

• Real time activity dashboard management.

The platform enables fintech organisations to:

• Offer a range of omnichannel customer touchpoints;

• Provide end-to-end platform advantage, covering retail and business financial services;

• Deploy engagement strategies through dashboards. 2. Products

The RedCloud One platform contains a number of product Clouds, each of which support particular features. The financial services cloud, and agent cloud are described in the following sections.

2.1 Financial Services Cloud

The Financial Services (FS) Cloud is RedCloud's flagship product covering the breadth of use-cases across the digital financial services landscape. The Cloud enables financial service providers to deliver innovative and reliable solutions.

At the core of the product is RedCloud's transaction engine, which powers all financial activity across the Cloud. The engine supports the creation of single or multiple accounts for consumers, merchants and agents leading to a high degree of flexibility and scalability.

The FS Cloud supports activity across payments, savings, loans and insurance in order for your organisation to meet a variety of customer needs easily and effectively.

2.2 Agent Cloud

The agent network provides end-users with access to cash-in and cash-out services from e-money wallets in a market where standard financial instruments and bank branches are not easily available, low in number or not geographically viable.

The RedCloud One platform supports various types of outlet such as fully fledged banks, high street airtime dealers, petrol stations, supermarkets or small owner-run shops.

It is important that the outlets are provided with support and information and tools. The RedCloud Agent features include:

• Individual Employee identification and authentication via PIN regardless of the Ul/device;

• Java MIDlet, android and mobi-site in-store facilities;

• Store and network float management facilities;

• Employee cash management reporting for end-of-day reconciliations;

• Store float usage reporting; • Back-office facilities for more detailed reporting and management;

• Agent hierarchy modelling: centrally-owned, centrally-managed, and independent stores;

• Automated commission payment;

· Super- Agent facilities for Business cash-in/ cash-out.

3. Accounting Model

The RedCloud One platform creates a bank-standard accounting environment. The platform creates one or more accounts for every registered user in the system — individual or business. Each account is subject to full double entry bookkeeping, and a complete audit trail of all transactions is available at any time against any account in the system.

Figure 9 illustrates how RedCloud One provides a single platform for agency banking, B2B banking and personal banking. The platform offers a complete end-to end integration platform including: applications open API, Business intelligence, transactions and infrastructure.

Accounts are held in the secure central hosting facility; the end user channel (eg mobile phone) is simply a user interface and authentication/communication mechanism for the account. No funds are held on the end user device itself.

The accounting system is based on the model of a pooled (or shared) bank account: all funds in the system are backed up by a real-world control bank account held in trust by the MTO. The control bank account is one-for-one mirrored by a control account in the accounting database, with a highly controlled business process to ensure that the balance in the pooled account matches that expected by the RedCloud 1 platform. Thus, at any point in time the money held in trust for customers can be accounted for and returned on demand.

Figure 10 shows a diagram of the RedCloud One platform accounting model. All funds held within the RedCloud One platform are reflected in aggregate in an internal control account; this is mirrored in value by an external, real bank account sample The service is first primed by depositing cash into the trust bank account. Once funds are deposited, the equivalent e float funds can be distributed across the system, typically from the MTO to Agents or other actors. These actors can then interact with end-users.

Electronic Fund Transfers, bank account based transactions, only happen where money is deposited or withdrawn to another bank account; the rest belongs within the platform when end users interact with the system. The RedCloud One platform allows the MTO to hold multiple bank accounts and mirror each of these into the system independently. This allows the spread of pooled funds across multiple banks.

A non-exhaustive selection of payments types typically used by end-users include:

• Cash In;

• Cash Out;

• Send money (P2P);

• Buy Prepay Airtime;

• Pay merchant (C2B - Bill payment and Point of Sale payment);

• Salary payment (B2C);

• Government Disbursements (G2P). Beyond domestic payments, the system has the capabilities to support international payments, in addition to savings, loans and insurance activity.

Figure 11 shows a diagram illustrating RedCloud's smart integration module, allowing rapid and smooth integration.

Figure 12 shows a diagram illustrating RedCloud's integration with 3^rd parties, providing:

• Easy self-integration for 3^rd party partners;

• Multi-protocole and evolutive integration;

• Asynchronous SDK;

· Constant system responsiveness.

4. Regulatory Information RedCloud complies with jurisdiction and business specific AML and KYC requirements. The RedCloud One platform covers the main KYC and AML concerns in the following way:

• The platform has a robust real-time registration process, capturing key Know your Customer (KYC) information and storing it against the customer financial records.

• Tiered KYC Rule bands allow different rule limits based on the customer risk profile.

Customers who are able to provide additional KYC information, such as proven address, photocopy of their ID or introduction from their Employer or Financial Institution, can be placed in Rule bands that allow higher transaction limits. The Rule band implementation also allows for the prevention of transaction smurfing (splitting large transactions into multiple smaller ones).

• Phone sharing can be officially supported by the system without a risk of integrity loss; this is because the system models the user and PIN separately to the device being used. It is possible to model in the system multiple users sharing the same phone, as demonstrated by the in-store agent employee functionality.

• AML limit checks can be enforced via the Rules Engine.

5. Service Management

Figure 13 shows a screenshot of the Administration web-portal from which the service provider can manage the service on a day-to-day basis. A variety of activity can be carried out from here, including:

• Customer Relationship Management;

• Transaction activity review;

• Transaction activity— for actors other than consumers (eg agents and merchants);

• Setting up new accounts for multiple parties;

• Bank Reconciliation;

• End user transactions including bulk payments and scheduled payments;

• Settings;

• Reports/Analytics.

5.1 Customer Relationship Management (CRM)

The RedCloud One platform offers an optimised Customer Support Request (CSR) process that gives a streamlined process for finding and verifying a customer, this also allows creating of audit trails covering access and activity against a specific customer account.

The key customer service business processes are available on the back office website, via a customer care login. These include:

• Unlock the PIN;

• Resend a Start PIN;

• Reverse incorrect transactions (with appropriate checks via maker-checker business process);

· Answer transaction queries;

• Change customer account status;

• Change customer mobile number;

• Change customer rule band;

• Change customer charge band.

When changes are made to a customer's account, an SMS is automatically sent. 5.2 Analytics

The platform contains a large number of pre-configured reports that support the core management processes and is built on the Microsoft Reporting Services framework. Access to the raw data cube and the process of designing and adding additional reports based on available parameters in the system can be shared with users.

The platform includes the following analytics:

Management Reports:

• Number of customers & customer acquisition rate;

• Transaction Breakdown (number, value);

• Transaction Revenue;

• Cost Generating Transactions;

· Number of Customer account balances;

• Customer monthly transaction;

• Customer fees;

• Agent Monitoring; • Acquisition;

• Transaction Numbers by Network;

• New customers by Network;

• Float usage;

· Compliance;

• Reversals volume;

• Data modifications by web operator;

• High Usage accounts. Agents Activity Reports:

• Float Level Monitoring;

• One liner to describe what it is;

• Historical Float Usage;

• Transaction Monitoring;

· Reconciliations;

• Commission Due.

Finance Reports:

• E-Money ownership;

· Commission Due;

• Bank Reconciliation Snapshot;

• Control Account Monitoring.

The main OLTP database used to track transactions is not optimized for reading data - it is intended to provide rapid processing of large numbers of write operations. The data it stores is also distributed over lots of different tables to reduce duplication and the associated overhead of writing to multiple locations. For generating reports, we need a different kind of database which is optimized for fast reading. The data we need for these reports is extracted nightly and placed into the data warehouse for use by the reporting system.

The RedCloud MFS platform makes available two categories of reports, Database and Cube (Data Warehouse), • Database Reports are available in real-time online;

• Cube (Data Warehouse) are (usually) nightly data transfers into the data warehouse.

Here the time interval is configurable depending on the transaction volume that needs to be processed.

We provide an industry standard tool to exports reporting data and create custom reports with different types of charts and graph of their choice.

Data exports to fill external data warehouse is facilitated via sharing the data dictionary. The actual data exports are analogue the RedCloud MFS Cube Data extracts.

Different KPIs are created for different dimensions of the mobile payments business such as MTO, Agent Management, Bank, Compliance, Registered Customers, Revenue, Transactions, System, Customers and following some of different KPIs based reports: · Transaction Information by Network;

• Network Transaction Breakdown and Float Usage;

• Business Transaction Reconciliation;

• Transaction Daily Breakdown;

• Revenue Daily;

· Revenue Monthly;

• Cost Generating Transactions;

• Cancelled and Declined Transactions.

RedCloud delivers circa 100 rich reports to fully take advantage of our business intelligence suite.

The business intelligence suite lies on the deep understanding of the consumers.

Red Cloud:

· collects the different actors parameters such as: transactions, user activity, agent and store activity, user identification.

• Analyses: reports, liquidity management, transaction profitability, AML & compliance, KYC (identification). • Develops: optimized business processes, fraud prevention, new products, increase transactions, customer profiles, artificial intelligence, machine learning.

6. Configuration Management

The platform empowers service providers to tailor the system to make it their own. There is a range of tools that permits a wide variety of parameters to be fine-tuned in accordance with the specific needs of particular markets. RedCloud 1 enables providers to quickly and easily define transaction parameters like features, language, charges, workflows and notifications. End user interfaces can be re-skinned and presented in the organisation brand.

Figure 14 shows an example of myRedCloud, a task-oriented browser-based configuration tool. The myRedCloud module uses intuitive task-orientated inputs and drag and drop user interfaces; service providers can directly configure parameters without the need to go to their technology vendor, resulting in a service that is nimble and one that quickly accommodates customers' needs.

Examples of features of myRedCloud include:

• Graphical deployment configuration

o Transaction fees, commissions, features, workflows, localization;

• Fast time to market

o Develop and launch new features quickly, and easily;

• Low cost approach

o No lengthy and expensive consultancy projects;

• Test changes offline and deploy production system

o Via a point and click, drag and drop interface;

MyRedCloud enables sector-leading levels of flexibility and customisation, resulting in organisations being able to tailor their services to their exact requirements and create propositions that carry maximum appeal.

A suite of wizard-like tools guides administrators to carry out a range of activity including customising end-user features, transaction charges, accounting rules, end-user notifications, language settings and interface menus. They can also determine know your customer (KYC) and anti-money laundering (AML) procedures and to model business processes or workflows.

This level of customisation can be achieved without needing to write a single line of code or to manually enter information into database tables. In doing so, organisations can now get to market quickly, as My RedCloud dramatically reduces the time it takes to launch tailored features and services.

Platform administrators can even configure, customise and manage RedCloud One deployments pre-launch as well as during the lifetime of the service.

As a self-service tool it dramatically lowers the cost of developing features and services and businesses can easily test, refine and deploy changes in a controlled environment. Key features available to organisations are: · Add new features for end users across payments, savings, loans and insurance products;

• Customise the charging model and which parties are involved in a transaction;

• Configure accounting rules, such as the maximum volume and value of transactions end-users are permitted;

· Customise notification messages users receive;

• Model business processes into efficient transaction workflows;

• Integrate with an external API;

• Deploy packages of configuration for easy, quick and effective enhancements to pre- production and production environments.

· Modify the end user experience by adding a brand logo, colour schemes and content.

7. Service and Communication Channels

Multiple mechanisms are available for customer UI on various device types. Each market will choose a suitable option for customers and launch only the appropriate services. RedCloud are able to advise on the benefits of each of the various options.

7.1.1 Service Channels

The RedCloud 1 platform allows end users to interact with the system using any of the following protocols: Unstructured Supplementary Service Data (USSD): available through API integration;

Interactive Voice Response (IVR): available through API integration;

Smartphone (IOS and Android application), which can be white labelled to fit the customer brand identity;

• Open SMS;

• Web interface. RedCloud provide a range of configurable smartphone interfaces as just one of the end user protocols that it supports. Examples of these can be found below. Live deployments have bespoke features that are not necessarily represented below. Designs are subject to updates and changes at RedCloud's discretion. Figure 15 shows an example of an app that is available to the agent. The following functions may be available through the app: customer registration, primary assistant settings, assistant registration & removal, cash deposit & withdrawal, bill payment, reporting & float usage. Figure 16 shows an example of an app that is available to the merchant. The following functions may be available through the app: online & in-store payment, bill payment & generation, statement generation, loyalty management, loan generation, store & order management, reporting & float usage.

Figure 17 shows an example of an app that is available to the consumer. The following functions may be available through the app: service registration, pin setup, money transfer P2P, bank account, wallet, cash deposit & withdrawal at agent, online & in-store payment, merchant & bill payment, balance & transaction history, loan request.

Figures 18A-D and 19A-D show further examples of smartphone interfaces. 7.1.2 Service Channels/Device Types

This table details the available user interface options for the various types of users and the roles associated with them.

USSD Java MIDlet App Web interface Subscriber • • • •

Agent •

Agent Worker • • • •

Merchant • •

Scheme Back Office •

In general, the communication of the RedCloud MFS platform with its users is based on communications templates and menu templates that are displayed or sent as associated events occur and the corresponding workflows are executed. The presentation in the individual user interface type is dependent on the channel that the user uses. However, some channels do not support certain functions like the back office.

7.1.3 Communication Channels

Via the Java MIDlet, users can use GPRS/Wi-Fi or encrypted SMS. During the commission phase of the platform, there is a requirement to interface with third party systems to provide the communication channels.

RedCloud One supports the following communication interfaces:

• SMPP 3.4/3.5

o For SMS and USSD in some markets;

• SSMI

o For USSD Gateway interaction;

• ETAPI

o For services such as IVR, smartphone, WebPOS, third Party systems, custom web access, open APIs and other interfaces. The External Transaction Application Interface (ETAPI) can be accessed via the internet.

8. Security and Permissions

The RedCloud One platform processes transactions securely. For example, some guiding principles include:

• Complete transaction privacy for each financial institution;

• Transactions cryptographically encrypted;

• Communications secured by SSL certificate (html);

• Regular penetration testing;

• ISO 27001; • One-Time Pin;

• Maker-Checker to validate high-impact transactions;

• The platform encrypts all SMS's sent from the java MIDlet, as well as replay detection software at the server side to detect for potential foul play;

· All API and mobi-site traffic is over HTTPS, with a VPN between the servers and any integrations where possible;

• All back office administration website access is by certificated access;

• There are password requirements for all web users, and passwords must be changed regularly;

· All actions performed are audited by the system;

• The system disallows access to actions where the web user is not given permission;

• Most financial actions on user accounts and critical business processes require 2 people to act— "maker checker" principles.

8.1.1 Financial Security

When analysing financial fraud it is evident that the majority of fraud is internal. With this in mind RedCloud One platform workflows have implemented all financial transactions with the Maker-Checker principle in mind. This ensures that nobody can create and approve financial transactions. Additionally, the RedCloud One platform based on a multiple layer online transaction engine that records all transactions and stores them in multiple locations. It also records who has initiated and approved transactions. Thus it is possible to reconstruct any transaction that went through the RedCloud One platform. The Auditing capabilities of the RedCloud One platform allow to follow transactions through their stages and see the involved parties, as well as a report based approach as well as the Business Intelligence engine and its associated Data Warehouse allows the differentiated analysis of transactions. 8.1.2 Connection Security

The RedCloud One platform is designed to provide maximum financial inclusion. Nobody should be excluded from the financial service offering due to equipment. When reviewing the capabilities of the various available channels, they are quite varied in their capabilities where connection security is concerned.

OpenSMS offers only the security of the GSM signalling channel. Therefore, it offers the lowest level of connection security. That means it needs to be handled through Transactional Security. The concept is explained below.

IVR+DTMS+SMS also offer very limited security where connection security is concerned. However, it needs an intrusion into the voice and data systems of a network operator, or Mobile Base Station in order to gain access to voice and SMS communication. Again this Channel needs to be handled through Transactional Security.

USSD offers communication through the GSM signalling channel with the added benefit of being able to encrypt the user PIN. This provides some basic level of connection security, but it also should have the benefit of additional Transactional Security.

SIM ToolKit uses the same communication options as USSD, but allows additional program code to be executed and would therefore allow session encryption and the use of crypto algorithms and securely stored keys in the SIM card. However, this requires considerable program code and would require a much larger storage SIM card, which is normally not popular with the Mobile Network Operators. Furthermore, it will exclude all end-users without the correct SIM card. For a MNO this may be considered a neat way to reduce churn, but will not be popular with the users and limit the available market size.

Java Midlet is available on many feature phones and provides excellent security as it uses session encryption methods and presents the user with an advanced graphical user interface. The majority of the phones deployed in Indonesia fall at least into this category. It is also supported by Blackberry's Midlet emulator.

Smartphone and Web Apps are the most advanced User interaction methods. They allow the implementation of high security SSL sessions and the custom code can additionally encrypt or generate secure cryptograms to secure communications and sign transactions. Currently supported are Android and iOS for the End-user and Agent, as well as Android for the Merchant. The Web Interface is available for end-user and Agent.

8.1.3 Transaction Security

When considering security for mobile Money systems it needs to be clear that any transaction real or fraudulent is traceable and reversible until the money is physical withdrawn in cash.

Even at that point the RedCloud One platform can provide the ID of the withdrawing individual.

In order to defraud money from an RedCloud One platform it is necessary to move money into fraudulent channels and then use real IDs to withdraw the cash. Low End Devices

In many cases the size of transactions that are done of low end channels are small and therefore Transaction Limits can be set to levels that make it economically unviable for criminals to attempt fraud. RedCloud One platform allows to set transaction value limits and transaction number limits over several time periods.

That means even if someone would find a way to insert fraudulent transactions into the system it would be exceedingly hard and longwinded to manage to withdraw the stolen cash.

RedCloud One platform has implemented the same security policies as the original M- Pesa system. To this day the security concept for the user interface has held up. This goes to show that the original GSM security concept fortified with Transaction Security Limits can successfully combat fraud.

High End Devices

Higher class devices like feature phones, smartphone and Web or eCommerce applications it is possible to execute custom software to provide state of the art connection security and the transaction security limits can be relaxed.

If required additional measures can be implemented like SMS notification for unusual transactions based on geographic, spending behaviour, transaction frequency and subscriber movement can be added.

The RedCloud MFS platform has the feature of being able to configure all transaction workflows. This allows then entry of additional Workflow items, such as fraud detection. The fraud detection action connects to the VAS API which can be configured to connect to an external Web Service of a Fraud Management tool. This means that any Fraud Management tool which offers Web Services can be integrated into all relevant workflows by simply configuring the workflows and the VAS API. If there is a need for a different API integration, other than Web Services, then a communications stub needs to be implemented that will fit into the VAS API. This allows the integration with any Fraud Management tool that provides APIs to 3rd Party Software.

There are three types of audit trails are kept in the RedCloud MFS platform:

• Security Log;

• Transaction Log;

· Activity Log.

There is the History database which keeps the history of all the changes to an identity in the platform. The Archive database contains all regulation relevant data which is kept depending on the business rules of the customer for financial year accounting and how long data has to be kept. The Customer can specify the extent of this archiving.

The information for auditors can be extracted through the Back Office Interface or specific Audit reports. Users logging in from a mobile device are identified with either an MSISDN/PIN combination, or a Username/Password combination when logging in from a Web Interface.

The identification is the MSISDN or the username and the authentication method is password or PIN. This means of authentication was chosen to maximize accessibility for lower end devices. The workflow for the login and authentication is configurable and can be extended to incorporate additional means of authentication, like OTP or fingerprint ID where this is appropriate.

Sensitive data is encrypted on all user channels which allow custom encryption of line or data elements (all user channels except OpenSMS). Once the data arrives in the Workflow engine it is decrypted and re-encrypted with the data base key.

All data is held in MS SQL Server 2012 Enterprise Edition with the Database Encryption Feature enabled.

9. Fraud & Compliance

The RedCloud MFS platform complies with the accounting rules and the rules for data collection in the KYC process. Additional Compliance for AML and CFT is contained in the Compliance Module. This is a separate software module that uses the RSS feed of global publishing companies or Compliance Database providers. These update using live feeds the RedCloud MFS platform database with current AML/CFT data on persons and organizations. This requires a subscription to the service of the feed provider. When enrolling new subscribers, the data provided is searched in the AML database and if found the account opening may be declined, or an entry to a watch list and a message to law enforcement may be generated seeking guidance on the processing of transactions on this individual. Later on any transaction partners in financial transactions are screened to be listed in the Compliance database, with the transaction either declined or delayed for further guidance from law enforcement.

In case of delay the user is notified that the transaction cannot be processed at this time and will be notified when the transaction is completed.

These workflow actions can be configured in the transaction workflows of the RedCloud MFS platform.

The RedCloud MFS platform can integrate with external Compliance database provider by using their APIs and use the internal Compliance API Stubs to integrate with the services of companies like Lexis-Nexis or Dow Jones. However, this should only be used if high bandwidth data services are available, as the checking of the transaction partners needs to happen online and if there are significant delays in the data transfer it will slow down the overall system performance.

If this is not available, the locally held database may be the better option and only an online update feed for updates of new information will flow into the database and enquiries can be satisfied locally.

The RedCloud One platform is implemented with a channel based and layered security in mind.

9.1.1 Anti-Money Laundering

An important aspect of providing a mobile money service is Anti Money Laundering and Counter Terrorism regulations. It is the recommendation of the World Bank that the scope of AML and CFT obligations on a money transfer platform ought to be determined using a risk-based approach. The World Bank believes that policy makers need to modify their specifications according to local necessity in order to be realistic, flexible, and driven by a risk-based analysis in their approach to AML and CFT regulations. They recognise that AML and CFT regulations that do not recognize local conditions may hinder efforts to expand financial access.

The RedCloud One platform covers the main AML concerns in the following way:

• The platform has a robust real-time registration process, capturing key KYC information and storing it against the customer financial records.

Thus, customers who are able to provide additional KYC information, such as proven address, photocopy of their ID or introduction from their Employer or Financial Institution, can be placed in Rule bands that allow higher transaction limits. The rule band implementation also allows for the prevention of transaction smurfing (splitting large transactions into multiple smaller ones). • Phone sharing can be officially supported by the system without a risk of integrity loss; due to the fact the system models the user and his PIN separately to the device they are using. It is possible to model in the system multiple users sharing the same phone, as demonstrated by the in-store agent employee functionality.

· AML limit checks can be enforced via the Rules Engine.

The RedCloud One Administration portal provides a full suite of account management tools. Account transaction history can be monitored, searched and reviewed. Individual accounts can be blocked or suspended pending further investigation. Automated rules can be configured to detect suspicious behaviour and automatically block accounts.

Any transaction/workflow modelled in the platform can be customized to include integration with any external data source providing KYC data validation— e.g. Lexis Nexis. This allows real-time checking of customer details, either at the time of registration, or at the time of transacting. The workflow model can be customized to react accordingly depending on the result of the KYC validation checks.

Customized reports can easily be implemented allowing a real-time view of any potentially suspicious behaviour. These reports can be fed into our rules engine to automatically flag/highlight or even suspend associated accounts.

10. Transaction Activity

10.1 Transaction Engine

The real-time transaction engine is the core of the RedCloud 1 platform.

A Workflow is configured against each allowed transaction, to ensure a business process is followed; for example— it is important that when operating on a customer account from the back office website that the system enforces strict maker-checker policy, so that it is not possible for a single person to act on a customer's funds.

Most mobile transactions are real-time, taking only the time to deliver the response to the user to confirm that the funds have been moved. However due to the transaction life- cycle process, it is possible to enforce transaction "stop and wait" when required. For example, this has been used in the past to wait for an SMS delivery receipt before confirming the financial money movement. This mechanism is used to ensure that only control account transactions can be confirmed when an entry is visible in the control bank account statement. The system is configured off the shelf with many Transaction Types defining the financial interactions executed using Workflows that define the business process behaviour associated with the transaction.

10.2 Transaction Types

The RedCloud 1 platform includes standard transactions that can be delivered to the customers with minimum development. Customers have the ability to configure the transactions rules (commissions and Rules).

These transactions include the following: 10.2.1 Standard Sendees

All the transactions mentioned below assume that the debit and credit party of the transaction are using the RedCloud wallet.

This platform is used for the operation of mobile Financial Services. The services that can be provided include:

• Customer registration:

o Registration at Agent: Customer goes to any registration agent, provides KYC documentation. The Agent completes registration through a dedicated agent application;

o Bulk creation: customers can be bulk created through the bulk creation tool;

• Money transfer to registered & unregistered Subscribers;

• Merchant payments on wallet;

• Cash deposits at agent;

• Cash withdrawals at agent;

· Automatic collection of recurring payments;

• Agent Management solution: Agent registration and float management;

• Reports and analytics;

• Accounting Services; • Bulk Payments;

• Bank reconciliation (providing integration with core banking software). 10.2.2 Optional Services

Optional services typically require customised integrations, excluded from the standard license price. A non-exhaustive list of typical integrations includes the following:

• Core banking integration: This allows customer to move funds from their bank account to their mobile wallet and from their mobile wallet to their bank account;

• ATM integration: Allows customer to deposit and withdraw cash at an ATM without using a card;

• Pre-paid services top up, for example, airtime top up, pre-paid utility payment

• USSD integration;

• Card integration.

10.3 Charging Engine

Billing, charges and commission management is a vital part of any financial system. The RedCloud 1 platform provides a range of features to ensure that charges and commission structures are flexible and fully automated. While standard values are provided, these can be extended by the MTO to provide granular tariffs as required.

Every financial transaction on the RedCloud 1 platform transfers a principle value between 2 parties. In addition to the principle value money movement, a potential charge can be levied on every transaction.

All charges created by a transaction request are tied to the same transaction receipt as the principle value movement. When a transaction is queried via a back-office system, full details of both the principle value and all the charges levied will be returned, including details of the parties who paid and received the charge.

The charging engine flexibility allows:

• Multiple charges, for example, to allow decoupling of customer charges and agent commissions into separate models;

• The choice of who pays for the transaction and who receives (sender, recipient, or another third party); • Charge amount profile, percentage of transaction amount, percentage of previous charge amount, fixed fee and transaction banding are all possible;

• Per transaction type, the choice of whether the charge amount is based on the debit or credit party's charge band, or a combination of both. For example, when paying a bill, the charges are dependent on the contract between the bill payment company and the MTO, not between the customer and the MTO. This model allows for each bill payment company to have a different negotiated fee, and a different split of how much the customer pays (in most cases this is zero), and how much the bill payment company pays.

Figure 20 is a graph showing an example of the kind of profile that can be configured: Charging revenue and Proportioning. The MTO can customise the charging tariffs required via the myRedCloud web browser based configuration tool. The subsequent value variation will be supported via management tools.

10.4 Rules Engine

All users are placed into a Rule band which govern the amounts the customers are allowed to transact. The rule engine checks transaction values to ensure that limits have not been breached by either the debit party or the credit party. Typically, the basic rule engine is configured to check the following:

• Minimum debit party account balance;

• Maximum credit party account balance.

• Minimum/Maximum transaction value, can be different on different groups of transaction types.

It is possible to add to these cumulative rule checks. Generally, regulation calls for annual limits on the account; many airtime providers require daily airtime purchase limits:

• Daily Limit, Monthly Limit and Annual limit are the 3 most commonly used cumulative rule types.

Multiple rule bands can be configured. It is possible via the back office interface to change the rule band on a customer account, and as such give the customer more or less financial capability. This is the centre of the system's Anti-Money Laundering (AML) implementation; rule bands are primarily used to reduce the risk of fraud and money laundering. Where a customer can demonstrate that they are in a lower risk category, the rule band can be changed to allow more freedom to move larger amounts of money.

10.5 Technical Transaction Processing Detail

The transaction lifecycle has a number of transition states to allow for adequate transaction records to aid exceptions processing and customer follow-up.

Key checks performed during the transaction lifecycle include:

· Party Resolution;

• Charge Allocation;

• Authentication and Permission checking;

• Rule Engine checks;

• Account Status Checks;

· Transaction Expiry checks;

• Workflow actions checks (for example, successful Start PIN generation).

Figure 21 shows a diagram representing the general interaction within the platform for processing of client initiated financial transactions: This generic flow is customised for new features and/ or to support custom workflows for MTOs.

11. System Architecture Overview

The RedCloud One platform is based on the Microsoft Windows Communication Framework (WCF). WCF includes predefined bindings for most common communication protocols such as SOAP over HTTP, SOAP over TCP, and SOAP over Message Queues, etc. Interaction between WCF endpoint and client is done using a SOAP envelope. SOAP envelopes are in simple XML form, which makes WCF platform-independent. The RedCloud One platform is highly extensible. Each integration with an external party is developed as a standard plug-in for the RedCloud One platform. How the plug-in connects to the external party is determined by the API(s) available on the 3rd party system. The RedCloud One platform is scalable through its capability to not only spawn multiple threads of the Application services, but also multiple services, which can run on multiple server systems accessing the same data. As the servers have been implemented stateless the database is the complete data reservoir needed for the execution of a thread. This is coupled with a database lock mechanism that allows individual threads and services to lock particular data until it is processed. In order to be able to keep a reasonable processing speed we have implemented the Redo Cache Server in the RedCloud One platform to keep the Database performance high.

If a service should not be able to complete a transaction, the transaction if freed after a timeout and completed by an alternative service or thread.

Figure 22 shows a diagram of the system architecture of the RedCloud One platform: The architecture of the RedCloud One platform is based on the classic three-layer software architecture with Data, Application and Presentation layers. Additionally, the RedCloud One platform has an Integration Layer that serves to knit together the Application Layer with the various types of Presentation Layer options the system offers.

The RedCloud One platform adheres strictly to the principles of layered software architecture, where the different functional layers are clearly distinct and allow the easy introduction of new functional groups into the architecture using or extending existing Interfaces.

This increases the maintainability of the software and facilitates adaptability.

In order to be able to keep a reasonable processing speed we have implemented the Redo Cache Server in the RedCloud One platform to keep the Database performance high.

The following sections describe the layers and their component services. 11.1 Data Layer

The Data Layer incorporates the data in such a way to make it easy to use throughout the system. The key goal of the database organization is data availability, speed of access, concurrency of access and recoverability in case of error.

It contains a number of databases and tools to perform this role:

• The Online Transaction Processing (OLTP) database stores transaction-oriented application data.

• The Historic database is the traceability record of the RedCloud One platform operation.

• The Archive database is the storage for OLTP data no longer required for daily operation.

• The Sequel Server Integration Services and Sequel Server Analytic Services (SSIS/SSAS) is a set of Microsoft (MS) SQL Server tools for extraction and analysing of OTLP data for use in the RedCloud Data Warehouse.

• The Data Warehouse (DW) contains the Business Intelligence for detailed data analysis.

11.2 Application Layer

The Application Layer incorporates all the services that make up central functions and the business logic of the RedCloud One platform. The architecture diagram shows the three layers inside the Application Layer:

• Core Services are common services with essential functions of RedCloud:

o Finance Services, the internal ledger;

o Identity Services, to add and maintain identities inside the platform;

o Security Services, provides authentication and authorization services; o Crypto Service, provides all cryptographic functions;

• Workflow Processing is the engine that executes configurable workflows:

o Workflows;

o Transaction Actions;

o Activity Actions;

• Business Logic is for rule checking, data import from Banks and miscellaneous services:

o Workflow Scheduling; o Bank Statements;

o MSISDN Number Plans;

o Business. 11.3 Integration Layer

The Integration Layer is responsible for the integration of the Application Layer. This is important due to the multitude of different delivery channels serviced by the system.

The Integration layer consists of several blocks of functionality:

· Service Provisioning, provides menus according to user communication data

• Incoming Messages, transport messages to message handlers;

• External Application Interface (ETAPI) service, the communication interface;

• Outgoing Message Queue connects VAS, Bank Switch and Communication Services;

• VAS services, Value Added Services interface for airtime top-up;

· Bank Switch service, implements the interface to a Banking Funds Switch;

• Communication Service, handles outgoing messages to the different Channels;

• Channel Drivers, render and adapt outgoing data for specific channels like SMS USSD, or IVR. 11.4 Presentation Layer

The Presentation Layer is the part of the system that presents the data to the user and gathers user input to be delivered to the system.

The Presentation Layer of the RedCloud One platform comprises of three interface types:

· Back Office Management website

o Web Channel for the Admin Web site and the Reporting system.

• Public Internet website

o Web based system implementing the Web frontend for the customer handset applet, it also allows the sending of Bulk email.

· Handset interface

Handset Presentation module is the main user interface; it provides a channel for the user to interact with their accounts. A number of channels are currently supported: • Smartphone App, gives the user a GUI for quick and easy access to mBanking facilities.

• Java MIDlet, gives the user a GUI for quick and easy access to mBanking facilities with Feature phones.

· USSD, a text based menu system providing access to the mBanking facilities for basic GSM phones. However, this does need integration with a Mobile Network Operator to provide a USSD gateway and star code.

12. Capacity and Performance

The RedCloud One platform is scalable through its capability where multiple threads of the Application services can be created, as well as multiple services that run on multiple server systems accessing the same data.

To keep a reasonable processing speed the Cache Server has been implemented in the RedCloud One platform, this will ensure the Database performance remains high.

If a service does not complete a transaction then a timeout will occur and that transaction is freed up, the service will then be completed by an alternative service or thread.

The Cache Server has shared memory. It is scalable so that more servers can be added for faster processing of user requests.

Figure 23 is a diagram showing the process of cache filtering of requests through various servers, in which requests are filtered through the cache via many servers discreetly and quickly.

13. Networking and Connectivity

The platform currently runs on a set of Windows 2012 R2 Servers in an Active Directory domain utilising SQL Server 2008 SP1 (or higher) as the database. It is recommended that the platform should be spread over a minimum of four servers as each have a role in the operation of RedCloud 1 System.

The servers are named logically to show each role:

• Application AP; • Web WB;

• Integration INT;

• Database DB. 13.1.1.1 Application Server

The Application Server hosts the application programs. These are the Microsoft Windows Communication Framework (WCF) application, Windows applications and a Services website. 13.1.1.2 Web Server

The Web Server hosts the websites. The main Admin website along with the secondary websites are hosted here. The Report Server can also be hosted here.

13.1.1.3 Integration Server

The Integration Server hosts the external application websites. This is where the MIDlet websites are hosted. The Application Programming Interface (API) services are also hosted on this server.

13.1.1.4 Database Server

The Database Server hosts the RedCloud 1 Database. The Business Intelligence (BI) system is also hosted on this server. The Report Server can also be hosted here.

13.1.2 Connectivity

For the platform to communicate effectively between all Websites, Services, Windows Services and Databases, the servers running the platform must be connected to a local domain. Accounts must be managed through Active Directory where each account will be unique to each service. This adds an additional layer of security for the platform.

The RedCloud 1 Product is intended for Banks, Mobile Network Operators and Micro Finance Institutions. The RedCloud One platform is based on the Microsoft Windows Communication Framework (WCF). The WCF includes predefined bindings for most common communication protocols such as:

• SOAP over HTTP;

• SOAP over TCP; • SOAP over Message Queues.

Interaction between the WCF endpoint and the client is done using a SOAP envelope. SOAP envelopes are in simple XML form, making the WCF platform-independent.

The main interfaces are:

• Admin Website;

• WebPOS;

• Customer Portal;

· Mobile Applications.

The RedCloud One platform is highly extensible. Each integration with an external party is developed as a standard plug-in for the platform. How the plug-in connects to the external party is determined by the API(s) available on the third party system.

13.1.3 System Diagram

Figure 24 shows a system diagram of the RedCloud One platform. 14. Deployment

Deployments for RedCloud One software are available in three ways:

• Public cloud;

• Private cloud;

• On premise. A single deployment is available, ensuring live service and sufficient resource usage using alerts.

The infrastructure is deployed on premises /private or public cloud. The key features are the following:

· Scalable solution: automatic size scale-in/ out;

• Speed of implementation: template design process;

• Pay as you go: OPEX cost structure;

• Redundant architecture and disaster recovery with multiple data centres. Figure 25 shows a diagram illustrating three deployment structures:

• Stored value account;

• Stored value account and synchronization;

· Non stored value account.

14.1 Public Cloud

This is provisioned on the RedCloud infrastructure as a service to maintain control of its behaviour and security aspects.

14.2 Private Cloud

This is a virtualised infrastructure within a data centre. RedCloud provides a basic set up for jobs, monitoring and optimisation from the database tier. 14.3 Integration

The RedCloud 1 platform offers the core platform services, and allow others to perform integrations against its APIs.

Initial integrations are often targeted at:

• Value Added Service (VAS) providers— aggregators who resell airtime, electricity vouchers and offer aggregated bill payments;

• USSD providers— to provide a customer interface in these channels in the local markets;

• Merchant integrators— for Point of Service (POS) device integration for agents and merchants;

· Banks - for automated bank reconciliation, Electronic Fund Transfer (EFT) payments and ATM Agents, as well as the potential for integration to move money from the customer wallet to another bank account and vice versa, and to query a bank account balance - for banked customers only;

• Payment Service providers (PSP)— in developed economies, for cash in from credit and debit card.s

Integrating the RedCloud One platform with third party services is performed by using the Value Added Service (VAS) for outgoing calls to external services and the ETAPI service for incoming calls from external services. These two services work together to provide third party integration with the RedCloud One platform. The dataflow of an integrated service is as follows:

1. User triggers an action by selecting a menu item on their handset.

2. The RedCloud application on the handset calls the ETAPI service on the server. 3. ETAPI looks at the token associated with the menu item (known internally as the

MenuItemPrompt) and routes the action to the correct handler.

4. If the MenuItemPrompt is associated with a VasAction, the RedCloud One platform loads the VasAction using its GUID and the action is called. The RedCloud One platform is designed to be extremely flexible, in that it is possible to configure custom transaction types, VAS channels, ETAPI services with any number of parameters and parameter types, as this is very complex, the product uses preset Vas Channels and preset menu items. For partners, the following preset menu items and VAS Channels are supported:

· PayBill;

• BuyAirTime;

• BuyElectricity.

Further channels can be configured, as well as custom parameters and transaction types. Due to the complexity of the work, this must only be handled after full training has been carried out by the RedCloud training team. Integration services are also provided on request.

14.4 Backup and Restoration

14.4.1 Database Backups

It is recommended that full database backups are taken for both system and user databases on a daily basis. The backups would preferably be stored at a different server than the one that hosts the SQL Server. Retain these backups for a minimum of 5 days.

14.4.2 Transaction Log Backups

It is recommended that Transaction log backups be taken at a frequency of no less than every fifteen minutes. To minimise data loss in the event of disaster, this frequency can be increased to, for example, every five minutes. As with the database backups, it is recommended that the Transaction log backups are stored in a different location to the SQL Server. Retain the backups for a minimum of five days.

14.4.3 Recommended Solution

RedCloud recommends the backup and maintenance solution by Ola Hallengren:

h ftp s : / / o la . hal i e ngren . c o rri .

This method creates objects necessary to backup all databases, including SQL Agent jobs. Within each job the following will need to be configured:

· Schedule of when the job will run;

• Retention period of the backups (in hours);

• Backup Location.

14.4.4 Restore

14.4.4.1 Database Mirroring

Mirroring is a method whereby the database is given a level of protection by redoing every insert, update and delete action on a secondary database. It is recommended that this is done synchronously to provide a hot standby. It can be done asynchronously (Enterprise edition only) to provide a warm standby.

14.4.4.2 Log Shipping

Transaction log shipping is a method to provide protection at the database level even though it has a latency of several minutes. Transaction logs are taken on the primary database, the files are then copied to a second server and restored to the secondary server. These steps are triggered by three SQL Server jobs: backup, copy and restore. Note: Logins need to be created on the secondary server and orphaned users fixed on recovery. 14.5 In-Service Upgrade

Any upgrade will be performed during a maintenance window agreed with the customer. Backups will be taken of all systems prior to the upgrade

15. Entity model One of the design goals of the RedCloud One platform was that it should be very flexible and suitable for use in multiple scenarios, not just simple mobile money transfer. A system designed by one organisation, solely for its own use, would be tailored specifically for that use. However, RedCloud sells to multiple clients, each with its own specific requirements and must be adaptable to each client's needs with minimal effort to keep down costs, lowering the base price for the system and maximising the potential client base.

For example, a mobile money operator might want a system that represents a single mobile money operator, many end customers, agents, etc. whereas an agency banking client might want to represent a single chain of agents, and multiple banks on whose behalf it operates but not hold customer details since they are the banks' customers. A utility company, such as an electricity supplier, may want to represent itself, its customers, their electricity meters, meter readings and when they were taken, etc.

The generic entity model is designed such that it can represent these and similar use cases solely through configuration changes, without requiring changes to the database schema e.g. no new database tables or columns. Configuration changes are changes to the data contained in the existing 300+ configuration tables.

The core of the entity model is implemented through the database tables as shown in Figure 25.

Each entity is represented by a single row in the Identity table. Entities may be obvious things such as, but not limited to:

• people acting as:

o end customers,

o agent assistants,

o back office staff,

o loan disbursement and repayment officers

• organisations such as:

o agent stores.

o mobile transfer organisations (MTO)

o banks, o agent aggregators,

o C2B businesses such as utilities (Airtime purchase, electricity company), o MFI groups (a group of people mutually responsible for each other's loans)

equipment such as:

o agent terminals or less obvious things such as, but not limited to: geographical areas

o countries

o provinces

o districts

o cities

• Promotional vouchers

• internal service access identities

Although the Identity table has a TypelD column, this is not the principal way in which entities are differentiated. It is the Role table and the types of Role that are associated with a particular entity that determines what it represents and what it can do.

The flexible entity model directly communicates or integrates with:

• the RedCloud One platform Configuration Repository;

• the RedCloud One platform plugin architecture;

• Direct integration of accounting and mobile communications.

16. Mobile Payment Solution: SME ECO System

Figure 27 shows a diagram illustrating the merchant/ SME eco system.

Figure 28 shows a diagram illustrating the merchant/ SME eco system and highlighting the business-to-business (B2B) key features.

Figure 29 shows a diagram representing the B2B key features.

Challenges: ^• Delayed Payments

^• Delayed Accounts Information

^• Cash payments: Security & Liquidity

• Consolidation % Tracking of payment at the supplier/ distributor level

· Enabling merchants to facilitate other bill payments (utilities etc.)

Figure 30 shows a diagram representing the platform monitoring and controls.

Figure 31 shows a diagram incorporating a 3^rd party distribution service digital account platform. Merchant can buy the 3^rd party service credit at any agent or bank partner of the 3^rd party service digital account program. With his credit, the merchant will pay for his products and have access to special offers and vouchers only available for the 3^rd party service digital account community.

RedCloud One: Solution Description

• A smartphone based POS for delivery;

• Merchant powered via smartphone app;

• Instant Payment;

• Instant notification to delivery agent;

• Open platform allow integration with the Bank, Mobile Wallets, Card Schemes, Utility companies etc.

• RedCloud platform connected to Inventory Control & CRM systems;

• Rich Business Intelligence report to suppliers /wholesalers on performance of merchants;

• Possible extension to specific loyalty programs;

• Possible in closed loop mode (e.g. 3^rd party wallet) or open wallet.

RedCloud One: Solution ROI

• Efficient (Low Cost & Time) digital payment processing;

· Secure & Anti fraud mobile-based Digital payment solution;

• Drive engagement and sales in retail;

• Have a direct, continuous, two-way dialogue with Merchants;

• Analysis of sales, preferences and purchasing behaviour; Working capital liquidity management;

Feedback, Research & Development;

Creating innovative connected experiences;

Increase number of retail locations.

RedCloud One: Solution KPIs

• Number of large distributors registered to the system

• Number of merchants registered to the system

• Number of B2B transactions per week/month

· Value of B2B transactions per week/Month

Global turnover of merchant including: Distributor business+ other bill payment business

Challenges:

· Cash payments: Security issues, liquidity issues;

• Increasing customer loyalty;

• Consolidation and tracking of payment at the HQ level;

• Customer Bill payment;

• Merchant as agent: Setup and tracking of commissions;

· E-Commerce: On-line payment.

Figure 34 shows a diagram representing the full merchant cloud features.

RedCloud One: Solution Description;

• Merchant Powered via Smartphone App;

· Instantaneous payment;

• Open platform allow integration with the Bank, Mobile Wallets, Card Schemes;

• Loyalty points and promotional vouchers;

• Web Payment via wallet; • Merchant as agent: sophisticated commission structure;

• Possible in closed loop mode (e.g. Merchant wallet) or open wallet;

• Rich Business Intelligence report to the merchant managers or HQ. RedCloud One: Solution ROI

• Efficient (Low Cost & Time) Digital Payments Processing;

• Secure & Anti Fraud Mobile Based Digital Payment Solution;

• Drive Engagement and Sales in Retail;

• Drive customer loyalty;

· Analysis of Sales, Preferences and Purchasing Behaviour;

• Working-capital Liquidity Management;

• Feedback, Research & Development;

• Creating innovative Connected Experiences. RedCloud One: Solution KPIs

• Number of registered merchants;

• Number of registered customers;

• Number of C2B transactions per week/ month;

• Value of C2B transactions per week/Month;

· Global turnover of merchant including: retail & other bill payment business.

Figure 35 shows a diagram illustrating a merchant/SME eco system and highlighting the loans /micro credit key features. Figure 36 shows a diagram representing the loan/micro credit to merchant features. Challenges:

^• Cost of cash;

^• Cost of infrastructure;

^• Accessibility for remote areas;

· Payment delays;

^• Access to credit history;

^• Tracking and follow-up;

^• Help the SMEs grow their business. RedCloud One:

• Easy on-boarding: KYC, AML;

• Faster cash cycle: Reduced cost of cash;

· Tracking of payment history/ credit scoring;

• Business Intelligence.

RedCloud One: Solution KPIs

• Number of registered merchants;

· Number of registered Credit companies;

• Number of new loans per month;

• Average amount and duration of loan;

• Default payment rate. Figure 37 shows another diagram illustrating a merchant/SME eco system and highlighting the business-to-government (B2G) key features.

Figure 38 shows a diagram representing the B2G key features.

Challenges for tax payment:

· Heavy administration work;

• Delayed payment;

• Tracking.

RedCloud One:

· Instantaneous payment;

• Tracking;

• Reporting.

17. Case Studies

17.1 Financial payment network

Figure 39 shows a screenshot of a mobile app connected to a system that was deployed for managing interoperable agency banking and mobile financial payment networks. A network of over 1000 agents is deployed, allowing access to a large number of banks and financial institutions. The mobile app includes the following key features: customer registration, over the counter transactions, utility bill payment and airtime top up.

17.3 Agency banking

Figure 40 shows screenshots of an agent app and of a consumer app. On launch day, over 5000 users registered.

The case study includes the following features:

• P2P transfer;

• Airtime top-up;

• Pre-paid electricity bill;

• Salary payment;

• Agent management;

• ATM, USSD integration;

• Arabic translations;

• Central bank integration.

APPENDIX: KEY FEATURES

A. A flexible entity model A computer-implemented system that enables the deployment of configurable and customizable financial services, the system including (i) a transaction processing subsystem and (ii) a data store that stores a flexible entity model, which is a hierarchical model that represents the different multiple actors which the system needs to be used by, and the relationships between the different multiple actors, and (iii) an interface between the flexible entity model data store and the transaction processing sub-system; and in which the transaction processing sub-system is accessible by any new entity that is configured to conform to the flexible entity model and that is also configured to exchange data over the interface. Optional features include:

• Actors include: agent, super-agent, customer, place, e-commerce company, regulators, insurers, manufacturer, distributor, merchant, bank, retail group or any FMCG (Fast Moving Consumer Goods) company, technology vendor, telecom operator, government institution, savings and loan company.

· The flexible entity model enables rapid, low cost compliance with changes to the regulatory or central bank environment.

• System can be integrated with both feature phones and smartphones.

• System can be integrated with an existing bank system.

• The system is customized for each actor in order to apply to different scenarios. · A geography model can be captured within the flexible entity model.

• The system is configured to track, record and store all financial transactions between the different multiple actors.

• The system automatically calculates fees such as transaction fees, commission fees.

· Financial transactions include: payments, ordering, stock, delivery, invoicing.

• Each actor is able to access the system using an application.

• System directly integrates with other 3^rd party system or application. • Multiple tables define optimal re -usable components, and enable fast, reliable and low cost roll out of new services.

• System holds configuration data in an optimal structure both in memory and in a database to allow efficient processing of transactions.

· System provides tools that ease the creation of the configuration data and enforces rules that prevent incorrect configuration being installed.

B. Shadow accounts for the unbanked

A computer-implemented system that enables the deployment of configurable and customizable financial services, the system including (i) a transaction processing subsystem and (ii) a data store that stores a record of a shadow account for each unbanked user with a unique ID, and in which the data store tracks all events, and commissions and charges in respect of each shadow account, so that all events, and commissions and charges arising when agents or merchants provide services to each unbanked user, is tracked in the shadow account record in the data store; and (iii) an interface between the transaction processing sub-system and the data store.

Unbanked users need a unique ID but no mobile phone

Shadow accounts are processed centrally.

Shadow accounts update accounts in the core banking system in real-time for regulatory transparency.

Access to insurance services via agents, is tracked using shadow accounts.

Access to e-commerce services via agents, is tracked using shadow accounts. Access to health services via agents, is tracked using shadow accounts.

Access to education services via agents, is tracked using shadow accounts.

Shadow accounts are used in the context of a mobile payment system.

Shadow accounts are continuously monitored and tracked.

All transactional (and non-transactional) related events are recorded.

Charges and commissions are calculated and recorded for each transaction.

Charges and commissions are also linked to an entity model as defined above. System can be integrated with an existing bank system. C. Core banking abstraction layer

A computer-implemented system that enables the deployment of configurable and customizable financial services, the system including (i) a transaction processing sub- system and (ii) a database that stores a record of transactions and (iii) an interface between (a) the transaction processing sub-system and the database and (b) the core banking system, the interface being an abstraction layer that separates or insulates changes to the architecture or structure of the transaction processing sub-system or the architecture or structure of the data store from affecting the core banking system.

Optional features include:

• A web-based tool enables a bank to roll out new services without the need to integrate the new services directly with the core banking system or to re-engineer the core banking system.

· A web-based tool allows the bank to configure or update a large number of different databases without interfering with the core banking system.

• New transactions are configured directly via the web-based tool.

D. Simple form-based UX for customers and agents A computer-implemented system that enables the deployment of configurable and customizable financial services, the system including (i) a transaction processing subsystem and (ii) a database that stores a record of transactions and (iii) an interface between (a) the transaction processing sub-system and the database and (b) end-users' mobile telephones; in which the mobile telephones display a form based graphical UX (user interface) that is configured to operate with the interface; and in which different forms can be added to the form-based graphical UX to enable different services to be offered or different customer segments to be served, without the need to re-configure or adapt the transaction processing sub-system or the database that stores a record of the transactions and without the need for custom integration with different mobile phones. Optional features include:

The user interface allows the same services to be offered to different channels. • The user interface allows for a form to be created.

• The user interface allows the one or more form to be reused.

• User profiles are created and incorporated into 'culture groups'.

• A form is associated to a function, for example the function of: receiving messages, sending messages, submitting a message.

• The forms are adapted to feature phones and/ or smartphones.

• No device integration complexity or core banking integration are required.

E. Dynamic, extensible plugin based workflow A computer-implemented system that enables the deployment of configurable and customizable financial services, the system including (i) a transaction processing subsystem and (ii) a database that stores a record of transactions; and in which the system is configured to support new plugins that are added to the system to enable different workflow actions or steps to be undertaken, without the need to re-configure or adapt the transaction processing sub-system or the database that stores a record of the transactions, other than to operate with new plugins.

Optional features include:

• Configuration data is stored in tables that define optimal re -useable components. · Plugins can be added to the system without requiring the reconfiguration of the system.

• Plugins can represent an action/ step in a particular workflow.

• Example of plugins: workflow actions, activity actions, validation actions, and transactions actions.

· Workflow can be suspended or resumed.

• System can be integrated with both feature phones and smartphones.

• System can be integrated with an existing bank system.

• Workflow can be reused to prevent hard coding of the system.

F. Designed for agency services A computer-implemented system that enables the deployment of configurable and customizable financial services, the system including (i) a transaction processing subsystem and (ii) a first interface between (a) the transaction processing sub-system and (b) agency service providers, the first interface being a modular, extensible interface that defines how agents interact with the system and are paid commission by the system and (iv) a second interface between (a) the transaction processing sub-system and (b) the core banking network;

in which the first interface is configured to separate or insulate changes in how agents interact with the system and are paid commission by the system from either affecting the core banking system or having to be directly integrated with the core banking system.

Optional features includes: · The charging structure in the system allows for different business models to be implemented by users of the system.

• System enables efficient and successful business models emphasizing central role of agency payments.

• System updates agency management in real time, e.g. paying commissions and other incentives are immediately updated, with instant update of rates etc. for maximum market responsiveness.

• Amount of commissions can be specified on a periodic time period such as an hourly or weekly basis.

• System directly integrates with existing agents networks: Such as petrol station chains, giving agents access to a vast new range of services to sell.

Generally applicable optional features:

• System is designed for agency services.

• System is designed for merchant services.

· System is designed for digital account based services.

• System is designed for the unbanked, even those without mobile phones. • Shadow accounts are processed centrally.

• Core banking system accounts are updated in real-time.

• System is completely configurable and at low cost.

• System is regulatory transparent.

• System rapidly and cheaply adapts to new regulatory or central bank requirements.

• System supports regulatory approval.

• System supports best practices.

• System supports products covering various customer segments:

o P2P, B2B, B2C, G2P;

o Microsaving/loans;

o Bill payment;

• The system supports end to end technology solution:

o applications;

o open integration modules:

o business intelligence;

o transactions powering;

o infrastructure.

Note

It is to be understood that the above-referenced arrangements are only illustrative of the application for the principles of the present invention. Numerous modifications and alternative arrangements can be devised without departing from the spirit and scope of the present invention. While the present invention has been shown in the drawings and fully described above with particularity and detail in connection with what is presently deemed to be the most practical and preferred example(s) of the invention, it will be apparent to those of ordinary skill in the art that numerous modifications can be made without departing from the principles and concepts of the invention as set forth herein.

Claims

CLAIMS A flexible entity model

1. A computer-implemented system that enables the deployment of configurable and customizable financial services, the system including (i) a transaction processing subsystem and (ii) a data store that stores a flexible entity model, which is a hierarchical model that represents the different multiple actors which the system needs to be used by, and the relationships between the different multiple actors, and (iii) an interface between the flexible entity model data store and the transaction processing sub-system; and in which the transaction processing sub-system is accessible by any new entity that is configured to conform to the flexible entity model and that is also configured to exchange data over the interface.

2. The system of Claim 1 in which the actors include one or more of the following: agent, super-agent, customer, place, e-commerce company, regulators, insurers, manufacturer, distributor, merchant, bank, retail group or any FMCG (Fast Moving Consumer Goods) company, technology vendor, telecom operator, government institution, savings and loan company.

3. The system of Claim 1 or 2 in which the flexible entity model enables rapid, low cost compliance with changes to the regulatory or central bank environment.

4. The system of any preceding Claim in which the system can be integrated with both feature phones and smartphones.

5. The system of any preceding Claim in which the system can be integrated with an existing bank system.

6. The system of any preceding Claim in which the system is customized for each actor in order to apply to different scenarios.

7. The system of any preceding Claim in which a geography model is captured within the flexible entity model.

8. The system of any preceding Claim in which the system is configured to track, record and store all financial transactions between the different multiple actors.

9. The system of any preceding Claim in which the system automatically calculates fees such as transaction fees and commission fees.

10. The system of any preceding Claim in which a financial transaction include: payment, ordering, stock, delivery, invoicing.

11. The system of any preceding Claim in which each actor is able to access the system using an application.

12. The system of any preceding Claim in which the system directly integrates with other 3^rd party system or application.

13. The system of any preceding Claim in which the data store stores multiple tables that define optimal re -usable components, and enable fast, reliable and low cost roll out of new services.

14. The system of any preceding Claim in which the system holds configuration data in an optimal structure both in memory and in a database to allow efficient processing of transactions.

15. The system of any preceding Claim in which the system provides tools that ease the creation of the configuration data and enforces rules that prevent incorrect configuration being installed.

Shadow accounts for the unbanked

16. A computer-implemented system that enables the deployment of configurable and customizable financial services, the system including (i) a transaction processing subsystem and (ii) a data store that stores a record of a shadow account for each unbanked user with a unique ID, and in which the data store tracks all events, and commissions and charges in respect of each shadow account, so that all events, and commissions and charges arising when agents or merchants provide services to each unbanked user, is tracked in the shadow account record in the data store; and (iii) an interface between the transaction processing sub-system and the data store.

17. The system of Claim 16 in which the unbanked users need a unique ID but no mobile phone.

18. The system of Claim 16 or 17 in which shadow accounts are processed centrally.

19. The system of Claim 16 - 18 in which the shadow accounts update accounts in the core banking system in real-time for regulatory transparency.

20. The system of Claim 16 - 19 in which access to insurance services via agents, is tracked using shadow accounts.

21. The system of Claim 16 - 20 in which the access to e-commerce services via agents, is tracked using shadow accounts.

22. The system of Claim 16 - 21 in which the access to health services via agents, is tracked using shadow accounts.

23. The system of Claim 16 - 22 in which the access to education services via agents, is tracked using shadow accounts.

24. The system of Claim 16 - 23 in which the shadow accounts are used in the context of a mobile payment system.

25. The system of Claim 16 - 24 in which the shadow accounts are continuously monitored and tracked.

26. The system of Claim 16 - 25 in which all transactional (and non-transactional) related events are recorded.

27. The system of Claim 16 - 26 in which the charges and commissions are calculated and recorded for each transaction.

28. The system of Claim 16 - 27 in which the charges and commissions are also linked to an entity model as defined above.

29. The system of Claim 16 - 28 in which the system can be integrated with an existing bank system.

Core banking abstraction layer

30. A computer-implemented system that enables the deployment of configurable and customizable financial services, the system including (i) a transaction processing subsystem and (ii) a database that stores a record of transactions and (iii) an interface between (a) the transaction processing sub-system and the database and (b) the core banking system, the interface being an abstraction layer that separates or insulates changes to the architecture or structure of the transaction processing sub-system or the architecture or structure of the data store from affecting the core banking system.

31. The system of Claim 30 in which the a web-based tool enables a bank to roll out new services without the need to integrate the new services directly with the core banking system or to re-engineer the core banking system.

32. The system of Claim 30 or 31 in which a web-based tool allows the bank to configure or update a large number of different databases without interfering with the core banking system.

33. The system of Claim 30 - 32 in which new transactions are configured directly via the web-based tool.

Simple form-based UX for customers and agents 34. A computer-implemented system that enables the deployment of configurable and customizable financial services, the system including (i) a transaction processing subsystem and (ii) a database that stores a record of transactions and (iii) an interface between (a) the transaction processing sub-system and the database and (b) end-users' mobile telephones; in which the mobile telephones display a form based graphical UX (user interface) that is configured to operate with the interface; and in which different forms can be added to the form-based graphical UX to enable different services to be offered or different customer segments to be served, without the need to re-configure or adapt the transaction processing sub-system or the database that stores a record of the transactions and without the need for custom integration with different mobile phones.

35. The system of Claim 34 in which the user interface allows the same services to be offered to different channels.

36. The system of Claim 34 or 35 in which the user interface allows for a form to be created.

37. The system of Claim 34— 36 in which the user interface allows the one or more form to be reused.

38. The system of Claim 34— 37 in which user profiles are created and incorporated into 'culture groups'.

39. The system of Claim 34— 38 in which the form is associated to a function, for example the function of: receiving messages, sending messages, submitting a message.

40. The system of Claim 34— 39 in which the forms are adapted to feature phones and/ or smartphones.

41. The system of Claim 34— 40 in which no device integration complexity or core banking integration are required.

Dynamic, extensible plugin based workflow

42. A computer-implemented system that enables the deployment of configurable and customizable financial services, the system including (i) a transaction processing subsystem and (ii) a database that stores a record of transactions; and in which the system is configured to support new plugins that are added to the system to enable different workflow actions or steps to be undertaken, without the need to re-configure or adapt the transaction processing sub-system or the database that stores a record of the transactions, other than to operate with new plugins.

43. The system of Claim 42 in which configuration data for the plugins is stored in tables that define optimal re -useable components.

44. The system of Claim 42 or 43 in which the plugins are added to the system without requiring the reconfiguration of the system.

45. The system of Claim 42— 44 in which the plugins represent an action/step in a particular workflow.

46. The system of Claim 42— 45 in which plugins include: workflow actions, activity actions, validation actions, and transactions actions.

47. The system of Claim 42 — 46 in which the workflow can be suspended or resumed.

48. The system of Claim 42— 47 in which the system is integrated with both feature phones and smartphones.

49. The system of Claim 42— 48 in which the system is integrated with an existing bank system.

50. The system of Claim 42— 49 in which the workflow can be reused to prevent hard coding of the system.

Designed for agency services

51. A computer-implemented system that enables the deployment of configurable and customizable financial services, the system including (i) a transaction processing subsystem and (ii) a first interface between (a) the transaction processing sub-system and (b) agency service providers, the first interface being a modular, extensible interface that defines how agents interact with the system and are paid commission by the system and (iv) a second interface between (a) the transaction processing sub-system and (b) the core banking network; in which the first interface is configured to separate or insulate changes in how agents interact with the system and are paid commission by the system from either affecting the core banking system or having to be directly integrated with the core banking system.

52. The system of Claim 51 in which the charging structure in the system allows for different business models to be implemented by users of the system.

53. The system of Claim 51 or 52 in which the system enables efficient and successful business models emphasizing central role of agency payments.

54. The system of Claim 51— 53 in which the system updates agency management in real time, such as paying commissions and other incentives are immediately updated, with instant update of rates, for maximum market responsiveness.

55. The system of Claim 51 — 54 in which the amount of commissions can be specified on a periodic time period such as an hourly or weekly basis.

56. The system of Claim 51— 55 in which the system directly integrates with existing agents networks, such as petrol station chains, giving agents access to a vast new range of services to sell.

57. The system of any preceding Claim in which the system is designed for agency services.

58. The system of any preceding Claim in which the system is designed for merchant services.

59. The system of any preceding Claim in which the system is designed for digital account based services.

60. The system of any preceding Claim in which the system is designed for the unbanked, even those without mobile phones.

61. The system of any preceding Claim in which core banking system accounts are updated in real-time.