Building a banking assistant with MindMeld
Abhi Sidhu & Ritvik Shrivastava – In this post, we’ll take a look at our newest blueprint — a conversational assistant for common personal banking use cases.
MindMeld blueprints come with a pre-configured application structure and pre-built set of code samples and datasets. In this post, we’ll take a look at our newest blueprint — a conversational assistant for common personal banking use cases.
MindMeld provides example applications for common conversational use cases, called MindMeld blueprints, that comes with a pre-configured application structure and pre-built set of code samples and datasets. A blueprint allows you to quickly build and test a fully working conversational app without writing code or collecting training data. If desired, you can then treat the blueprint app as a baseline for improvement and customization by adding data and logic specific to your business or application needs.
In this post, we’ll take a look at our newest blueprint — a conversational assistant for common personal banking use cases.
Motivation & considerations
Before diving into the details of development, let’s talk about some key contributing factors behind the idea of this app.
With the growing popularity of FinTech, major financial institutions are looking at smarter solutions for providing their services to clients — conversational IVR, or virtual assistants, is one of the prominent targets.
The MindMeld platform, widely used for developing robust assistant applications, is ideal for the same. This serves as motivation for our new Banking Assistant blueprint: a virtual bank teller that shows off some of our amazing functionalities.
Value of time in large enterprises
Virtual assistants are efficient in terms of time spent by employees. Targeting lower customer interaction times by reducing the human-hours spent on solving previously seen issues is one of the major benefits. Also, AI-powered solutions are data-driven and can be improved with time and continuous training. This requires less time than training and re-training employees for the same.
For enterprises like banks, customers’ personal data is extremely sensitive. The MindMeld platform offers a significant advantage over cloud-based conversational AI platforms by allowing for data storage entirely on an organization’s local servers. This makes it advantageous for enterprise applications that are concerned about data privacy and security as data is never shared.
Now that we have our motivation, let’s take a look at the development steps.
Building the application
The Banking Assistant allows users to securely access their banking information and complete tasks as if they’re conversing with a teller. Below are some sample conversations for common banking tasks:
As part of the NLP component of any MindMeld app, we define a set of key use case domains or more fine-grained intents. The Banking Assistant intents include:
- Activating a credit card
- Applying for a loan
- Transferring money
- Paying off a credit card bill
- Activating AutoPay
- Checking account balances
For the complete description of the app’s architecture and a detailed breakdown of domains, intents, and entities, visit our documentation and refer to the illustration below:
Challenges & functionalities
There are a few unique challenges to building a conversational app for a banking firm, which we overcome through some of the MindMeld’s impressive built-in functionalities.
- Client authentication through MindMeld
In our vision for a production application, the frontend would handle user authentication and pass an immutable user token to the MindMeld application layer. This would allow the application to make calls to the bank’s REST APIs to fetch and update the corresponding user’s stored information securely. To show this, we mimic the passing of user tokens of the sample users in our database. When operating the app, one can pass the token for a specific sample user to only access data of that user and avoid leaks and cross-viewing of incorrect or mis-intended information. Find more information on the current set of sample users here and browse the data directory to find the user JSON data file.
- Learning about MindMeld entity roles
As mentioned earlier, the purpose of blueprints is to exhibit a ready-made app and to allow developers to learn about using the MindMeld platform. This app showcases some unique features mentioned above, as well as some finer details that are really useful. For example, the use of roles in entities. In our banking use cases, the ‘account type’ is a major entity, representing the users’ savings, checking, and credit accounts. While the entity is sufficient by itself, it might not be unique in use cases like money transferring, where two ‘account type’ entities are required. Defining a separate entity just for one use case is also not ideal. Hence we make use of entity roles. These roles represent the purpose for each use of an entity. Continuing with the same example, there will be two ‘account type’ entities for money transfers: one with the role ‘from account’ and the other ‘to account.’ The use of roles can be extended to a variety of use cases. In the case of a location entity in a travel app, the roles could be ‘departure’ and ‘arrival’ or ‘source’ and ‘destination.’
- Obtain missing information using slot-filling
Intents like transferring money or checking account balance require some key information such as account type, account number and amount of money. It’s likely that the user doesn’t provide this information in a single query, and the banking assistant needs to prompt the user for it. Instead of creating a back-and-forth logic to fetch missing information, we make use of MindMeld’s recently released slot-filling or entity-filling feature. We define a slot-filling form for each use case and let the feature prompt the user for this information on our behalf. You can read more about this feature here. A sample conversation using slot-filling for the money transferring intent can be seen here.
- Querying external storage with dialogue manager
The current Banking Assistant architecture showcases MindMeld’s support for secure REST APIs by mimicking PUT and GET API calls to retrieve and update information from a local data file. This is done through the Dialogue Manager of the app. This allows for the secure exchange of data and gives users the freedom to connect their REST endpoints and easily expand upon the backend. With this support, it’s easy to modify the underlying data storage as requirements change over time, with minimal design modifications to the app itself. It also allows for updates to the user data through secure API calls.
To give a glimpse of both the dialogue management functionalities of the app and the slot-filling feature, here’s a snippet of a dialogue handler code. The logic in this function (check_balances_handler) is fairly simple as you are only expecting one entity — an account type for which the user is checking the balance for. If the account type entity is not specified by the user the slot filling logic will be invoked. You can find an example of a more complex handler function for the Banking Assistant here
That covers a brief overview of our new Banking Assistant blueprint application! If you would like to try it out, you can find more information here. For help developing your own application, take a look at our documentation.
About the authors
Ritvik Shrivastava is a Machine Learning Engineer at Cisco’s MindMeld Conversational AI team. He holds his MS in Computer Science at Columbia University, specializing in Machine Learning and Natural Language Processing.
Abhi Sidhu is a Software Engineer at Cisco who specializes in providing practical solutions to emerging technological problems. He holds a BS in Computer Science from Cal Poly San Luis Obispo.
Click here to learn more about the offerings from Webex and to sign up for a free account.
Dec 2, 2022 — Lorrissa Horton
Dec 2, 2022 — Emily Brooks