Architecture and Integration

Chore Scout Architecture and Integration Overview

Moroku has built the Gen Z banking category, creating Chore Scout on top of its GameSystem platform to:

Improve financial literacy with children
Increase engagement, accounts and savings of younger customers for financial institutions

The solution comprises a pair of mobile applications operating against a cloud based server for the management of game mechanics and optionally integrated with our banking partners core banking system for account related activities (opening, payments etc). This is usually managed by connecting to a pre-existing mobile or Internet banking integration framework. Banks can also choose to deploy the application as a stand alone application with no integration.

This following highlights the overall technology architecture along with key areas of technical integration required and the main questions to be addressed with regard to this integration.

Mobile Applications

Chore Scout is a white label mobile banking application. Each time Moroku sells the application to a bank or credit union, the client provides Moroku with

A list of assets
Their core banking APIs so the parent can create accounts and transfer money between parent and child

With these, Moroku creates a new build of the apps in Android and iOS for the client as well as a new tenant for the client on the ChoreScout server. This build is produced using our automated CI/CD pipeline. Whenever we create a new production release, all client builds are also reproduced.Read More »

Game System

Chore Scout is built on Moroku GameSystem, the company’s financial services gamification and social media platform. GameSystem provides a broad range of capabilities employed to make financial services experiences fun, rewarding and ultimately, engaging.The GameSystem is made up of several parts. The main and most important part is the GameSystem Server. The GameSystem Server is a Ruby on Rails application that provides gamification to clients via APIs. It currently runs on Ruby 2.3.0 and Rails 4.2. The GameServer runs on Thin and is hosted on Heroku.

Multi Tenancy

The Moroku platform is multi-tenanted using a gem called Apartment. Each client (or potentially each team that the client has) has its own tenant managed by a Postgres Schema. When a new Tenant is provisioned, a new schema is created using the current database schema. When a new migration is added to the project, it is automatically run on each Schema that exists. There are three tables that are limited to the public schema only: Organisation, Tenant, and Delayed Job. Apartment will switch Schema when attempting to access all other tables. The Organisation and Tenant tables contain data that is not limited to a schema and is needed to find out the schema name for a particular tenant.

Apartments

The Game Server and ChoreScout server both consist of individual heroku apps (per environment – only dev at the moment for both apps) and are multi-tenant using the Apartment gem. This gem makes use of PostgreSQL Schemas to keep the data for each tenant separate. The public schema contains a small amount of configuration data and then each tenant schema contains all of the data for that particular tenant. Every tenant has its own subdomain to handle requests sent to the app.

Integration

To allow parents to set up their application, nominate the bank accounts from and to which allowance payments are made and then make the payments, the ChoreScout mobile application needs integration with the host bank’s core banking system.

Zero Integration

The first type of integration is no integration. We have assumed that success for banks deploying ChoreScout was children and families opening bank accounts. Maybe it is, maybe it isn’t. For those banks and credit unions for whom integration is too difficult or who want to run a pilot within Marketing and not involve IT until later you can now choose “Zero Integration”. The idea is also known as Paper Trading. Everything is on paper, with no money changing hands within the platform. This capability dramatically reduces project costs.

Device Registration

Routinely, mobile banking applications have a registration process where a user demonstrates that they are in possession of a specific mobile device and requests to use this device with the mobile banking app, to access their financial data. This process is often tied to the security model and may result in the bank issuing some form of credential that can be used by that specific instance of the mobile banking app on that specific device to access banking services.

Security Model

ChoreScout, as a Banking application, requires a high degree of protection to prevent fraud and theft. Generally, for mobile banking solutions, unlike Internet banking applications, customers are not required to authenticate themselves with a userid and password for each interaction. Instead they often authenticate themselves once and are then issued with some form of security key or token which can be used with each subsequent request. This token is then protected by a PIN or biometric measure.

Application Programming Interfaces

The Chore Scout application is designed to encourage specific banking behaviour from customers. While not a traditional banking application, it is important that the gamified app can execute a number of basic functions in a controlled way. The expectation is that target mobile banking or internet banking system provides APIs to support these features (they are common banking activities) and that these APIs are

Accessible to mobile applications outside of the firewall
Secured in a consistent and appropriate way
Accessible to Moroku’s applications assuming that the applications comply with security protocols

Its a great time to lead

Download our Integration Whitepaper

For more details on the ChoreScout technologies and how integration occurs with our banking partners please download our architecture and integration whitepaper below