Executive Summary
Now mobile banking has become the cornerstone of financial management, Midships is pioneering solutions to meet emerging consumer demands. One of our focus is to achieve two pivotal enhancements:
Offline Mobile Banking: We're revolutionising the way customers interact with their finances in connectivity-challenged areas. Our solution empowers users to view balances and prepare transactions offline, a boon for those in remote regions or reliant on intermittent Wi-Fi access.
Enhanced Performance: We're redefining responsiveness in mobile banking. Our architecture significantly reduces the latency from app launch to displaying the latest account status, ensuring customers have immediate access to their financial information.
Leveraged by Indonesia's first digital bank in 2019, the Midships Mobile Message Broker (MMB) framework is a testament to our commitment to innovation. Via an event-driven architecture, we empowered the mobile banking application to be more than just a window to its backend services. This architecture negates the need for the mobile application to perform synchronous data pull requests and instead keeps the application updated via event messages. This significantly reduced the time needed for the mobile application to be ready for use after user authentication. It also enabled offline accessibility of the mobile application to allow user interactions even when there is no internet connectivity .
Midships can provide expertise and capabilities to financial service organisations, integrating this cutting-edge solution into their existing infrastructures, thereby elevating the mobile banking experience for customers worldwide.
Background & Purpose
In the digital banking revolution, mobile banking applications have become essential for customers to manage their finances and execute transactions such as money transfers and bill payments. Users demand seamless, highly responsive solutions that provide comprehensive banking capabilities. Sometimes, they require these digitalised banking services to remain available without any internet connectivity to accommodate scenarios like travel. Some users may not have internet connectivity available to them all the time or have poor internet connection. The mobile banking solutions should be inclusive for those users by providing a good customer experience in situations where the internet connection is not available or not stable.
However, several banking practices have not aligned with these expectations, notably:
Synchronous Design: Banks often employ synchronous post-authentication data pulling on user’s full financial information. Due to the large amount of data to be pulled per user login, this approach often creates a long loading time for the app to enter the main dashboard. In addition, as the mobile application is often not designed to store any user financial information, retrieving user’s historical financial data per user login also places additional strains on the backend services.
Online Dependency: Traditional apps require an internet connection for access, where slow or unstable connections can degrade the user experience. While some apps offer offline viewing, they fall short in supporting transaction queuing for offline execution, which is crucial for users in areas with poor internet reception or during activities like flying.
This paper outlines Midships' innovative strategy to overcome these challenges through an event-driven architecture and by utilising a Mobile Message Broker (MMB) to integrate with the mobile app. Our approach, which has been successfully implemented with a digital bank in Indonesia, ensures a frictionless and efficient mobile banking experience, catering to the modern customer's needs for flexibility and reliability.
Midships Solution
Midships has recognised the necessity for an event-driven architecture that embraces asynchronous communication between the mobile app and backend services to fulfil the outlined requirements effectively. However, it is also understood that certain synchronous elements must be preserved. This balance allows customers to initiate manual updates, caters to scenarios demanding real-time information, and provides additional resilience in the event that the asynchronous service encounters downtime.
One key concept here is to change the perspective that a mobile banking app will be largely a stateless application. We still deem the backend to be the source of truth for a user’s financial data, but given the nature of a mobile app, it can hold a copy of the user financial data and be given only the changes in those data through event messages via a mobile message broker integration. This will allow us to realise the below benefits.
Performance Efficiency:
Data Stream Optimisation: As the mobile application is only retrieving the updates on the user’s financial information, the size of data streams are optimised. This reduces the strain on the backend systems, allows faster loading of pages in the presence of local data and reduces the amount of network traffic.
Latency Indifference: As the mobile application’s consumption of event messages is in an asynchronous manner, customer experience degradation due to network latency will be minimised. This means a customer can be in any part of the world and not feel impacted when utilising the mobile banking app.
Customer Flexibility:
Offline Accessibility : As the mobile application is holding on to a copy of the user’s financial data locally, read only operations remain available to customer in offline mode.
Backend Resiliency
Slowness Resilience: In an event-driven architecture, customers’ requests can be handled asynchronously where the response will be given to the customers via event messages. This means that connections do not need to be kept alive for an extended period of time due to database or system slowness. This ensures shared layers such API gateways and authorisation gateways will not be impacted and cause downtime due to slowness from downstream systems.
Other Benefits
Push Notification Capability: this solution also delivers push notification capability to customer devices that can be utilised in different use cases.
Transaction Queueing Capability: this solution also allows features on the mobile application to enable customer to queue transactions in offline mode and be executed once internet connectivity is obtained.
Global updates: Beside using the mobile message broker for customer level financial events, this solution also enable global level messages to be received by all the mobile apps.
Asynchronous communication, while advantageous, presents its own set of challenges that must be meticulously addressed:
Message Integrity Consideration
Event messages need to be complete and be delivered to the mobile application without information loss. To address this consideration, this solution proposes a pulling mechanism on the mobile app to begin retrieving the event messages from the mobile message broker at app launch. While the push mechanism to the mobile is more towards notifying the mobile app to carryout the pulling mechanism when its is running in the background or in an inactive state. The message broker must also ensure message order, uniqueness and durability such that the correct and complete information can be retrieved by the mobile app. In addition, the backend remains as the source of truth for the data and should continue to provide the necessary APIs for the application to reconcile the user financial information in the event discrepancies are raised.
Message Availability Consideration
Event messages need to be readily available to the mobile apps. This means the message broker should be scalable as per the customer base and has the required reliability to ensure there is no down time. A customer should not be restricted to a single device and the message broker should support multiple devices to retrieve a customer’s event messages.
Message Confidentiality Consideration
Event message should only be accessible by the authorised identity. In the mobile app context, we address data confidentiality on twofolds, First is that the message broker needs to support user level private channels where a user’s event messages can only be retrieved by that user and no one else. Second is that the message content should be encrypted and the encryption key should only be held by the mobile application and trusted systems in the domain of the organisation to ensure no one else will be able to peek into the content of the event messages.
By addressing these considerations, Midships aims to provide a robust, secure, and user-friendly mobile banking experience that aligns with the dynamic needs of today's customers.
High Level Solution Architecture
Key activities:
Setup
A) Upon opting for mobile banking, customers initiate the registration of their app and device with the bank's Customer Identity & Access Management (CIAM) service. The CIAM service will create a message channel token that the Mobile message broker (MMB) recognises. This token will have an expiry of 30days and include claims on the user’s identity reference ID and the private message channel assigned to the user. This token will be returned to the mobile app for it to persist for event message retrieval.
B) The CIAM service then coordinates with the MMB to establish a private message channel for the customer. The MMB will create a new message channel if the customer is new to mobile banking. If the customer is not new to mobile banking and is only registering due to a change of device, the MMB will identify the customer’s existing message channel to register the new device for push notification.
C) The CIAM service then coordinates with the Notification service to retrieve the message decryption key for the customer. Similar to MMB, the Notification service will create a new message key for encryption and decryption if the customer is new to mobile banking. The message decryption key will be returned to the mobile app via a secure key exchange mechanism for it to persist into OS level secure enclave for data decryption.
This streamlined setup ensures a robust foundation for a secure and efficient mobile banking experience, aligning with Midships' commitment to customer convenience and safety.
Updates
Banking services processed the transaction asynchronously and publish the completion result to the Pub/Sub service.
The Notification service subscribes to the completed transactions topic and receives the event message on the transaction completion
The Notification service encrypts the event message content using the user’s message encryption key and publishes the transformed event message to the user’s private channel on the MMB
The MMB signals the the Push notification service to send push notification to the user’s registered devices.
The Push notification service sends background notification to user’s registered devices to pull message events.
The mobile app receives the notification and subscribes to MMB’s user private channel with the message channel token to retrieve event messages of the user. The mobile app will filter out messages that are already stored and persists any new messages.
App launch
During app launch, the app should handle both offline mode and online mode.
Offline mode: If the device does not have internet connectivity, the app should facilitate a local authentication using OS level authenticator options. Upon successful authentication, unlock the message decryption key from the secure enclave to decrypt the stored event messages as well as the stored user financial data. The app should then process the event messages along with the user financial data to load the dashboard for the user and persist the newest user financial data in encrypted form into the device. Now the customer can interact with the app in offline mode.
Online mode: if the device has internet connectivity, the app should establish a subscription to MMB’s user private channel with the message channel token. The app should then facilitate the normal authentication flow with the CIAM service and additionally, upon successful authentication, requests the CIAM service to refresh the message channel token. The app should then carryout similar process as per offline mode to load the dashboard for the user. As the app’s subscription to the MMB will be kept alive in online mode, the app will receive in near real time the message events while the user interacts with the app.
Other Considerations/Decisions
Mobile Message Broker
While a custom-built event-driven architecture could address the challenges outlined, we also considered third party solutions. In 2018, Midships conducted a thorough evaluation of two leading services, PubNub and Ably. Our assessment revealed that both platforms offered:
Scalability: Robust solutions capable of supporting a vast customer base and their diverse device ecosystems.
Global Reach: Data centers strategically positioned worldwide, enabling message storage at the edge, closest to the customer, thus achieving minimal latency.
Reliability: Services boasting an impressive 99.999% uptime.
Durable messages: Messages can be persisted.
Low Latency: Less than 50ms from device to Edge Server
Quality of Service: A commitment to guaranteed message delivery.
Security and Efficiency: End-to-end message encryption coupled with message compression.
Seamless Integration: Compatibility with strategic CIAM solutions.
Secure Authentication: Utilisation of token-based authentication mechanisms (whose lifetime can be customised).
Additional Features: A suite of other beneficial functionalities.
We found that the comprehensive benefits offered by these third-party services significantly outweighed the costs and efforts associated with developing and maintaining a comparable in-house solution. By adopting a Mobile Message Broker, Midships ensures a cutting-edge, efficient, and secure mobile banking experience for our customers.
Transaction Queuing In Offline Mode With Digital Transaction Signing
In Midships' affirmID solution, we allow any transaction to be signed using a PKI approach similar to FIDO2 passkeys. The signing of a transaction in the affirmID solution can be carried out in offline mode and this can be used to queue signed transactions. When the app gains internet connectivity, the queued signed transactions can be posted to the backend services with the signature verified before processing.For more details on Midships' affirmID solution, please refer to this link: Midships | AffirmID, our low-code anti-fraud solutions for financial services
Are you interested?
If you would like to learn more, please contact ajit@midships.io