There are many layers to personalisation in digital banking, one of the first and most crucial layers is the categorisation of data. It is easy to get carried away with the UX design of an in-app widget or the look of a cross-sell advertisement. But if the data that is being used is not properly analysed and categorised the result will be financial wellbeing programmes or simple marketing use cases that lack the insight and intelligence to drive real engagement and change amongst consumers.

That is why categorisation of data, while only a small part of the personalisation pie, plays a pivotal role in driving customer engagement in digital banking.

What does categorisation of data mean?

In the context of banking specifically, categorisation of data refers to the organisation of transaction data based on pre-defined criteria, such as narratives, transaction types, merchant category codes (MCC) and other meta data, in order to facilitate the correct definition and grouping of transactions and form the basis for hyper-personalisation across banking channels.

Why is data categorisation important?

Transaction data contains some of the most useful information for banks to understand their customers. It provides incredible insight into how people live their lives, the things they like to do, the places they like to eat at, the countries they travel to, the items they regularly purchase, their sources of income and more. Categorisation makes data smarter, and more useful. It enables banks and their customers to get a clear and organised view of their everyday financial activities. By applying categories and other enrichments to transactions, it becomes easier to track, analyse and predict past and future income and expenditure, and more generally behaviours.

How does the Moneythor engine categorise transaction data?

To provide richer, actionable data to generate intelligent money management & loyalty features as well as personalised insights, the Moneythor engine performs transaction categorisation & enrichment in real-time and at scale across all types of accounts, cards, and e-wallets.

1. Raw Data

Moneythor’s high-performance engine consumes streaming or batched data sets of customer information across all their assets and liabilities such as accounts, cards, or digital wallets, as well as other banks’ data through Open Banking.

2. Categorised Data

From the raw data provided, the Moneythor engine looks for patterns and similar transactions to automatically assign the most accurate categories and enrichment strategies. The engine uses multi-lingual text analysis, rules based on regular expressions and priority levels, machine learning, external services where applicable and learning from individual customers’ choices as usage increases. Here is what is happening under the hood when categorisation takes place:

For transactions that cannot be automatically categorised or in the case that customised categories are preferred, categories can also be manually assigned in a self-service way by customers, triggering an automated learning process by the engine.

Each bank can also choose the most appropriate list of default categories to offer its customers, which can be customised depending on local needs and language preferences.

3. Augmented Data

Once categorised, the Moneythor engine can augment data further through transaction cleansing, adding merchant logos, detecting recurring patterns, bills and subscriptions, developing forecasts and more. From there, this categorised and augmented data is used to trigger personalised experiences across digital banking channels.

What if a customer wants to personalise categories?

From time to time, the way customers view their transactions may be different to how their bank would classify them.

That is why empowering customers with user-friendly opportunities to provide their feedback to the automated categorisation process is a must when presenting them with this information in digital banking channels.

Customers can add their own categories on the fly, potentially mix them with notes and hence truly personalise their experience. Over time, the engine learns such customer preferences and automatically apply them to subsequent transactions.

Bad data in, leads to bad data and poor experiences out. Categorisation and augmentation of data are critical for the successful implementation of personalised digital banking experiences. At Moneythor, we pride ourselves on providing our banking and fintech clients with advanced categorisation & enrichment capabilities, and a truly flexible and scalable engine.

Get in touch if you would like to learn more about how you could make more of your raw transaction data.

The post The Role of Data Categorisation in Digital Banking appeared first on Moneythor.

Blending enterprise-scale technology with market-leading expertise, Moneythor’s proven solution delivers unmatched business value by turning financial institutions’ systems of record into systems of engagement driving measurable business results, such as improved loyalty and NPS, lower cost to serve customers and increased revenue from more relevant campaigns.

Through this new module, the Moneythor solution’s capabilities have been enhanced to address the growing expectations of emerging and mass affluent as well as wealth management customers for personalised and engaging digital experiences throughout their investment journey.

With flexible integration options, the Moneythor digital engagement tool for wealth management can ingest a broad set of data, from retail accounts, cards and lending products to customers’ investment portfolios, holdings and Net Asset Value (NAV) feeds, including those sourced via Open Banking rails. The information is then used by the configurable Moneythor platform and its modern API to generate and deliver tailored insights, recommendations and nudges at scale and in real-time.

From dynamic widgets with details about their assets & liabilities to educational material and tailored insights, customers can then receive rich, actionable and contextual information to help them manage and grow their wealth.

The solution also becomes a fully configurable conduit to let customers update their risk profile, compare their investments against a model portfolio, receive relevant investment suggestions or use interactive calculators integrated into their primary digital banking experience.

Commenting on the launch, Olivier Berthier, CEO and Co-Founder of Moneythor, said: “Adding the ability to deliver personalised experiences across investment journeys was a natural evolution of our solution aiming to address the needs of financial services customers across all segments including retail, SME and now wealth. We are excited by the interest we have seen from our clients and partners for these new features, and how important personalisation and digital engagement are now to their wealth management strategies.”

To learn more about the Moneythor digital engagement tool for wealth management, contact us here.

The post Moneythor launches digital engagement tool for wealth management appeared first on Moneythor.

The Integration Library features a set of curated integrations that are interoperable with Vault Core, and is fully documented and validated. Vault Core’s joint solution with Moneythor delivers enhanced digital insights, recommendations and nudges for banks’ customers, utilising Vault Core’s real-time data feed to deliver categorised spending, financial management advice and goal setting capabilities among other user cases.

“Vault Core is a highly configurable platform which, through industry-standard APIs, easily connects and plugs into an ecosystem of technology vendors, allowing banks to build a best-in-class technology stack. In the past, clients would have had to undergo a comprehensive vendor selection process and build out integrations for each of their selected vendors, a costly and resource-intensive task.

Today, this challenge is now drastically simplified and reduced with our Integration Library – a curated collection of technology vendor integrations, interoperable with our core banking platform Vault Core, built either by us, or by best-in-class partners. The library makes it both easier and faster to select and build integrations to the other vendors needed around Vault Core.” – Bradley Steele, GM North America and Global MD Partnerships, Thought Machine.

Vault Core’s Universal Product Engine coupled with Moneythor’s unique solution delivers fully configurable, personalised, data-driven money management insights to consumers in real time, thus giving banks and fintech firms the ability to anticipate and respond to their customers’ continuously evolving financial needs while driving more personalised engagement and stickiness within their digital services.

Utilising Vault Core’s real-time data feed, banks can now provide data-driven personalisation to their customers, along with categorised spending & income details enriched with contextual and actionable financial wellbeing features powered by the Moneythor platform.

The post Integrating Moneythor to Thought Machine’s Vault Core appeared first on Moneythor.

—

At Moneythor, we are continually designing, developing, and redefining our digital banking platform to meet the needs of financial institutions globally. Our solution is a fully configurable orchestration engine and services that sit between data sources and customer-facing digital banking channels to deliver highly personalised and engaging experiences in real-time.

Our mission is not only to build a robust solution, but to also invest in research and development and to go beyond the limits of traditional architectures to better scale and address new challenging use cases like processing and analysing a large amount of data in real-time.

Each solution has its own advantages and drawbacks especially considering that we often run systems on legacy network and disk and keep CPU and memory cost under control. Without going all the way up to Alan Turing era, the characteristics of the problems the Moneythor solution deals with have long since been classified into two distinct categories, online transaction processing (OLTP) and online analytical processing (OLAP).

OLTP

The Moneythor solution offers an engine deployed between the financial institutions’ systems of record and their digital channels to power engaging and tailored experiences for end users. It is therefore expected that our solution can digest a large volume of data in real-time in a reliable and scalable way.

Relational database management systems (RDBMS) have historically been proven to be an efficient and reliable way to implement such OLTP system as they also offer an extremely valuable benefit of being ACID compliant.

Our solution also includes Personal Financial Management (PFM) features driven by APIs that can create, read, update, and delete personalised objects like budgets, goals, subscriptions and more. It is therefore crucial that the digital channels calling our API can unconditionally rely on their responses and for that purpose, our solution heavily takes advantage of the Atomicity, Consistency, Isolation and Durability (ACID) properties of the database whether it’s a RDBMS or not.

• Atomicity guarantees that all the modifications requested by an API call are completed successfully as a whole. That is, when our response is successful, one can trust that all the requested modifications have been processed or none when the response is not successful. Calling an API to create 3 budgets will create 0 or 3 budgets but never only 1 or 2.
• Consistency preserves the internal consistency of the database. No API call even if they are cancelled will ever let the database in an undesirable state. Calling an API to delete a goal will always delete not only the goal itself but its dependencies as well.
• Isolation ensures that one can call multiple concurrent API at the same time and the result will be the same as if the calls were processed one at a time. When calling an API to create a budget and at the same time, an API to modify a goal, both will be processed taking into account all these changes. All RDBMS use some sort of locking mechanism for that purpose and it’s worth mentioning that Moneythor chose an optimistic lock approach to avoid any database deadlock.
• Durability guarantees that after an API returns a successful response, no data will be lost in case of a failure. With API over HTTP, a common problem arises in case of a network failure when the client never get a response. For that reason, Moneythor implements idempotence to help clients retry without the risk of creating duplicates.

OLAP

The Moneythor solution enables the delivery of data-driven insights, recommendations and nudges tailored to each customer. This is where the analytical part of the solution shines and allows our clients to imagine a wide range of contextual and personalised nudges for their customers.

Such data analysis typically relies on a OLAP system optimised for that task and it is where friction can emerge when trying to build a solution on top of both OLTP and OLAP.

While being smart with what they can do with the data, OLAP systems work well when the data does not change a lot which is not a typical scenario with a digital banking solution that receives millions of transactions a day, in real-time and when data analysis is expected to happen at that time. Also, data can be changed by users themselves and this can lead to a completely different outcome when it comes to personalised nudges.

OLAP systems are not necessarily designed with fast response time as a top priority, whereas new user experiences built on top of the Moneythor API are served over HTTP and therefore synchronous. Waiting more than a few seconds for a screen to be rendered nowadays feels an eternity.

Distributed systems

Taking these constraints into account, the Moneythor solution leverages the best of both types of systems and mitigates their shortcomings through a distributed architecture with the characteristics below.

i) When the benefits greatly outweigh the cost of redundancy and additional processing, data in the persistent store is de-normalized on a case-by-case basis. This allows us to continue processing transactional data while keeping analytical processing time under control.

ii) The Moneythor solution sits between other systems and natively integrates with distributed event streaming platforms. For example, Apache Kafka is a very popular tool and together with the Moneythor solution greatly improves overall performances and simplifies implementation and scalability, because both systems are distributed by design. While APIs heavily rely on the ACID properties presented above and guarantee a response, when it comes to a stream of messages, Kafka and others usually offer 3 different message delivery modes: a message may or may not be delivered, a message can be delivered multiple times, or a message is delivered exactly once. The first mode is an obvious no-go when dealing with financial transactions, and while it might be appealing to look for an “exactly once” delivery, this comes at an extra performance and complexity cost. For this reason and because messages in Moneythor are idempotent, our solution is built around an “at least one” delivery concept which guarantees that no message will be lost, and consumers may simply control duplicates thanks to the idempotent flags.

ii) Finally, we cannot discuss distributed systems without paying attention to the CAP and PACELC theorems. The first one states that any distributed data store can only provide two of the following three guarantees:

Consistency (C): every read, every API call in the present context, receives the most recent version of the data or an error.

Availability (A): every API request receives a (non-error) response, without the guarantee that it contains the most recent data.

Partition tolerance (P): the system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.

In most instances, the Moneythor solution is deployed in an environment where there is only 1 logical instance of the database (with this database system generally running in a cluster for high availability). The number of partitions in this context is 1 but it would be a mistake to imagine that the system could therefore provide both consistency and availability at the same time. Indeed, in the absence of partitioning, the PACELC theorem refines those rules by stating that one must choose between Latency (L) and Consistency (C).

The Moneythor solution is designed to scale vertically by adding processing power and horizontally by adding additional instances in its cluster. It also exposes a set of front-end APIs used to enable rich interactive features to the end-users with the minimum response time possible for optimal user experience.

For these reasons, the solution is optimised for latency. While this choice may sound counterintuitive especially after stating that APIs rely on the ACID model, the definition of consistency is different here and does not apply to the data manipulated and computed by an API that must be consistent no matter what but determine when the most up to data will be available, immediately or eventually.

On the contrary, targeting consistency first would also mean that the system would have to wait for many instances in the cluster to be synchronised before returning a response since the solution uses in-memory caches to speed up processing and API response times. Despite the best in-class network and CPU, it would be extremely difficult to guarantee first class response times in that case.

Essentially, there are simple principles that can be implemented to dramatically reduce the risk of reading out-of-sync data. A properly configured load balancer routing requests in the cluster to the same instance where the data for the current context has already been processed and cached before is one example.

Conclusion

Building a highly scalable and real-time solution that combines transactional and analytics data is a trade-off between what features can be provided, what are the response times expectations and of course the cost of deploying and operating such a system.

Distributed and decentralised architectures can be complex to build, and it is necessary to understand their characteristics to keep their promises. Concurrently, technology is evolving, and high-performance computing is increasingly accessible, especially with Cloud platforms. These are the reasons why we have chosen to take this direction, now allowing us to serve successfully the data-driven personalisation needs of digital banks and financial institutions of all sizes.

To learn more about the Moneythor solution and our technology, please contact us.

The post Building Digital Banking Technology for Personalisation and Scale appeared first on Moneythor.

What does carbon footprint mean?

A person’s carbon footprint is the amount of greenhouse gases, primarily carbon dioxide (CO2), that is released into the atmosphere as a result of their activity. It is calculated by adding together all of the emissions from every stage of a product lifecycle or lifetime, (production, transportation, use-phase and end-of-life disposal), during which greenhouse gases are emitted into the atmosphere accelerating climate change.

Some of the key sources of carbon emissions include:

• Food – food accounts for 10-30% of a household’s carbon footprint.
• Fashion – because of the resources needed for production and the waste it generates.
• Residential electricity
• Personal transportation – automobile, air travel, rail transportation.

How can you track and offset your carbon footprint?

With so many sources of carbon emissions, working out a carbon footprint can be a complex process. How can we track every activity and assign the correct CO2 weight.

At Moneythor, we use transaction data to estimate a customer’s carbon footprint. Our engine analyses and classifies transactions and then assigns an estimated CO2 weight for each category (e.g. air travel, electricity, clothing) or for speficifc merchants / billers. The CO2 weight, which is measured in kgs, is assigned in real-time and is based on the average amount of emissions created during the production and/or transportation of a good or service. These averages and the related emission factors are generally determined by local specialist environmental agencies which our clients work with to develop a holistic carbon-tracking tool. This transaction-based approach is arguably not perfect as it generally doesn’t have access to full transaction details. For example, a single purchase at a retailer or e-commerce shop seen as a single transaction may include two products with very different CO2 impacts. However, it generally gives a fairly accurate estimate particularly when looking at trends.

The results of this tracking can be a simple overlay in CO2 kg equivalent to individual transactions shown within the mobile banking app’s transaction history or it can be used to create personalised trigger-based messages. Examples of these types of notifications and insights available in the Moneythor solution include detecting and alerting a customer to an increase or decrease in carbon emissions based on their recent expenses, creating carbon footprint trackers which are similar to a traditional budget tracker but are based on CO2 emissions rather than on spending amounts, and providing incentives to customers through rewards and points programmes that customers receive when a reduction in carbon consumption has been detected.

 
In reality, once the carbon emissions have been tracked and assigned their estimated weight, the possibilities for the content and insights produced within a bank’s financial channels are endless. Various carbon offsetting programmes, peer benchmarking and gamification tools are some of the ways that we can apply these insights and help customer’s to manage and reduce their carbon footprint.

When this pandemic ends and the world starts to look more like it once did, no doubt we will see a resurgence in carbon emissions. By providing customers with tools and initiatives that help them to lower their carbon footprint, we can support the environment when the new normal does emerge.

The post How Carbon Footprint Insights can Enhance Digital Banking appeared first on Moneythor.