Are you ready to implement Temenos Transact and design your future financial products? Have you considered an effective product path strategy to satisfy your ever-growing customer needs? Every business leader seeks right answers for such questions when you put your critical investments in line for aiding your banking operations. Product functionality coverage isn’t just enough to help you achieve your desired business goals, there is always a world outside of that which includes robust performance and easy maintenance of the product.
The essence of product design is to satisfy customer needs at every cost and maximize the returns from the product. In many cases, incorrect product design or improper integration lead to undesirable consequences. It is pointless to implement a market leading solution to your Bank without adequate planning for its optimal design and use cases. With my long association with Temenos Transact and experience in multiple implementation projects, I have penned down 7 tips to build your Transact products in a constructive way.
The 7 Tips to design your Temenos Transact Products
- Group products based on common functionality
As we know, the primary key benefit of Transact is Reusability. For the best utilization of it, the first step of product design should be identifying all common behaviour of your financial products. Accounts, deposits and lending being high level product line definitions in Transact, a financial product will fall into one of these high level classifications. Therefore, we can easily find the list of common behaviour of deposit products or account products. If we take account, the common behaviour can be savings, current or notice type of accounts. As another example for deposits, it can be common interest payment method like Interest pay-out or compound interest with deposit amount. If we have a clear definition that a set of products are applicable only for the group of customers belonging to a sector like salaried professionals, then that itself can be considered as a common behaviour. There are many other attributes to do this kind of grouping.
- Products which share same asset and liability column
- Products which have same tax benefits
- Products which needs additional charges
- Products which have same behaviour in maturity
- Products which will allow partial withdrawal
- Products which will change contracts into another product after some predefined time
- Exclusive products for rollover
Transact has property classes like interest, term and settlement and we will take an instance of it and build a product group. When we construct a product group, we need to group products based on the above listed common behaviours. It will give a strong basement to build further products.
- Decide your products as standalone or parent-child
After you brought the product group in place, the next step would be constructing products. How to decide the optimal approach for a product? Should we create standalone products or use parent-child concept? It is always dependant on each bank’s business and the right approach will minimize the maintenance of product in future.
To decide it, you need to list down all common functionalities at a side and different behaviour of the product at the other side. Do you sense that the common functionality is more and the differentiator is less, it clearly indicates you to follow parent-child concept bringing all common behaviour to parent? For Example, if a 5 year deposit is going to have fixed interest rate and a 1 year deposit goes to earn variable interest, we can create two child products just with different Interest definition whereas all the other components like payment schedule, settlement, maturity instructions, messaging, etc can be brought into the parent. Parent child concept is the best fit structure for products having more common features. On the other case there are few common functionalities but major is the difference, standalone products will be the right approach.
- Design Interest and Payment schedule components first
Interest component is a key attribute for products and sometimes it will change our product structure itself. It is very essential to detail the interest component prior to product definition. Kindly consider all features of interest component of your product like whether it offers simple interest/compound Interest, follows fixed interest or variable interest, periodic automatic Interest or Interest based on terms. It is necessary to consider all these factors and ensure our parent-child approach should not affect the independent management of interest/payment schedule components. This consideration will help out in the future maintenance of products or the respective products.
- Decide the pricing model of products
Transact has enabled us to have enterprise pricing feature (ie), even if we need different interest rates based on customer relationship, residence and channel, it is possible now to define all those variations within a single product.
What is the best utilization of this feature? Reduction in the stack of products. If you confirm that Interest alone goes to be different for different currencies/region/channel, you do not need to increase the count of products. Just bring all your business financial products into one single Transact product. Product variation will help us to define the variation and define different pricing for it under a single product. It is a great relaxation that we no need mess up our system with N number of products and redefine the same thing. This feature has a huge benefit while doing data migration from legacy system to Transact. Imagine that we are going to migrate 1000 of legacy contracts into one single product in Transact, what will be the result in the effort for data mapping? A very clear reduction at the effort and hence in implementation cost.
- Design products as per your reporting needs.
Why Core banking solutions enable all possible static definitions to be defined for contracts. Of course, it is to serve for financial reporting. All Income and expenses needs to be categorized properly in order to enable proper classifications in the reporting. Therefore, it becomes very essential to consider this point while designing a product itself.
All contracts of a Transact product are going to have same asset and liability category/ Profit& Loss category and so Banks should take a pause and confirm a product definition; it should not include any contract that needs to be columned differently in reporting. If we need different column for a set of contracts, they surely need a separate product.
- Consider eligibility checklist for products.
Do you check the eligibility of a customer to avail your financial products? If so, you can list out those eligibility conditions into two categories, one set as “Static checks” which will be verified only when a customer requests to avail a product for example credit score; another set as “dynamic check points” like customer age must be greater than 18 years. For dynamic check points, it is necessary to define eligibility component when u construct a product in Transact. It is our choice to check manually or through system for one-time eligibility checks. A product will have single eligibility component and hence we need to define an exclusive product if it has dynamic eligibility checkpoints.
- Decide how to track changes of product attributes
With the enhanced functionality of Transact, It is now the bank who will decide whether interest rate or charge attributes of a product can be negotiated or not at contract level.
Therfore, we need to list out all components of contracts and define whether it should be derived only from products and should not be changed at contract level. If so, they need to be defined as Tracking. If you need some attributes of a component like interest rate can be input only once at contract level and after that, it should not get changed, kindly make the component as custom tracking. The other group of attributes will fall under “Non-Tracking” category.
Wrapping Up
I am happy that I brought major product creation techniques through these 7 tips for the benefit of banks. Working with multiple implementation projects for different banks on Transact, I have discovered proper product definition will reduce the effort of implementation or data migration and so will reduce the operational cost as well as the maintenance cost in an immense way.
It is always advisable to plan and prepare well in advance, before you construct your next Transact product. As banks are looking at every possible way to drive operational efficiency, improve customer experience and shrink costs, a well-defined Temenos product structure is always the right move.
You can also catch some of the breath-taking features of Temenos Transact from my previous article in case you have missed.
