A Dispute Thesis — Pega Vs UDM

Day 180,181,182, 183, and counting …..

This is the average timeline for software deployment, if you are building from scratch, it is even longer.

Stumped right!

What if I tell you, that developing and deploying a dispute management software actually takes much longer than this and you guessed it right, we are talking about

Pega,

a low-code platform that lets banks build their dispute management software from scratch.

Coming to that, when you read the title, you might be thinking that this is one of the popular blog types where two products are compared.

You are not entirely wrong; it is a comparison but there is a tiny notation you need to pay attention to:

Unified Dispute Management (UDM) is a ready-to-go product for dispute management and

Pega is a low-code platform that needs to be planned, designed, coded, and developed by a team before it is live, hence the clock keeps ticking, ticking, and ticking……….

And this comparison will be in a table below for your quick reference. But we felt it best to take you through the ground realities of Pega-led software before proceeding further.

While it sounds so empowering that banks have a low-code platform that offers only a clean board to build custom-designed software to handle their operations, things are not so rosy on the inside.

And that’s what we aim to uncover.

Let’s start the process:

First, you need to purchase the license from Pega to build upon their low-code platform and this is of two types.

a) If you don’t want to incur the operational expense of setting up the infrastructure, you can get a recurring AWS license which will be hosted in Pega’s cloud.

b) If not, you can exercise the option of buying the package and hosting it within your environment.

Now that we have got it beat, let’s talk about the realities when you buy Pega’s low-code platform to build your dispute management tool in-house or within Pega’s AWS environment.

Now, you might be thinking, Yes, mission accomplished. I have bought the license from Pega, I have so many developers, and my software will be up and running in no time.

Let me press the brakes here for you and explain what will actually happen!

One of the highlights of getting Pega is that your in-house developer is of no use when it comes to building this system.

You need Pega-certified developers to develop the solution.

Yep, you read it right! And read it again,

Only Pega-certified developers can build your dispute management tool.

So, in a sense, it means that your operational cost has just gone up a spike because you have two options in front of you.

a) Get your in-house developer certified in Pega, which is a month and learning ability-dependent process meaning you will be paying recurring subscription fees/ expensive one-time payments for an IDE software that is simply staying put.

b) In case you skip this part and make a decision to hire Pega-certified developers, well they are a pricey bunch! Because offering educational courses and paid exams is another genius idea of Pega’s revenue generation streams. And these courses don’t come cheap and only a few developers take it meaning, demand is more than supply, ergo expensive!

But when you think UDM, these points don’t apply because there is no development from scratch. It will be self-hosted within your bank’s infrastructure without any compromise to your internal and external compliance policies.

Network Codes:

When hearing network issues, you might think we are going to talk about LAN configuration. No, sir, we are not! It is about card networks like Visa, MasterCard, and the like. So, most of the card networks broadly classify their reason codes on the basis of consumer dispute, fraud, authorization, and processing errors with their signature workflows and causes.

All these requirements must come from the business team and that has to be translated to the Pega developer’s language. Now, here comes the itch, which can be separated into three different perspectives:

Business Team:

First off, the bank’s business team must understand every single network reason code depending upon their card network association. The highlight of this activity is that every card network has its own update calendar. The standard schedule is twice a year. So, if you are building a dispute system in Pega, your business team must be skilled and fast enough to accommodate every change.

Consultants:

This workforce charges by the hour and they often function as the bridge between the bank and Pega developers (because consultants are the ones who recruit them as well). So, it is a repeating cycle where the business team cannot talk banking jargon to these consultants. They have to translate Klingon to Earth vocabulary and that’s no mean feat.

Pega Developers:

Now these people are those who predominantly work on detailed outlines and requirement documents received from the consultant or business team or Pega project/product manager. They cannot piece things together and will code just how they received the instruction.

If they can’t, it will become the game of princess telephone, meaning they will raise it as an issue, and the cycle of Pega developer > Pega project manager> consultant> business team and vice versa will be on repeat until their query is answered.

Now, let’s see what happens in UDM. Actually nothing,

We have got all this pre-programmed for your benefit. You don’t need to spend countless, billable man-hours to figure out everything. Our system has major network reason codes programmed and the system will automatically throw the relevant questions and based on the customer’s answer, it will assign the right reason code and get started with the next stages of the dispute.

Compliance:

In simple terms, Compliance is the hitchhiker’s guide to the galaxy of banking. It involves many aspects like data privacy, infrastructure requirements, internal and external policies that govern the business of a bank. In that order, dispute handling also has its share of compliance requirements from three separate levels of business, card network, and regulatory authority.

Let’s break this down further.

Regulatory:

This category consists of the Central Banks/Federal Banks/Any Fiscal regulators who govern the economics of the country. E.g. The RBI, Federal Reserve, and the likes. Their primary aim is to regulate the economic and fiscal policies including requirements, timelines, and implementation, applicable to both banks and individuals for a cohesive financial environment.

Card Network:

Well, these guys are the ones who power the entire network of payments, and they are a force to reckon with. Card networks are the ones who came up with the reason code and core rules and it is complete with deadlines, evidentiary requirements, and context that every payment card provider and acquirer must abide by.

Business:

Every bank will ensure compliance of these two big parties detailed above and set their own timeline essential to resolve the matter before the emphasized SLA. So, if the regulator and card network keep at 45 days, a bank will have an SLA of 30 days or so. This timeline will give them ample time to address any problems that might arise.

Sounds simple, why would that be an obstacle?

But, it is because the bank needs to liaise with too many stakeholders who hail from all these levels and translate the same to the consultant to carry over to the Pega developers. And this is no cheap and small feat. It involves a considerable fee component.

Because you will need consultants to communicate this to the Pega developer team and they charge by the hour. So, your operational ledger has another debit instead of credit!

P.S: This timeline changes for every reason code and category.

What happens in UDM?

UDM covers all three aspects of compliance right from L1 regulators to L3 Business. As a bank, you can set custom SLAs and TATs for every dispute you encounter. At the same time, UDM will offer auto-updates to the compliance module as and when released by the regulators and card network. In a nutshell, we’ve got you covered!

Operational Expenses:

Through the article, we have spoken about how operational expenses go up when you use Pega, let’s have a hypothetical calculation based on publicly available data.

Scenario:

Say you are getting about 20,000–30,000 disputes on an average every month, and you have anywhere around 70–100 analysts skilled in different stages of disputes struggling to manage this volume because, on average, the analyst can only handle up to 40 cases a day.

This results in irate customers, missed SLAs, TATs, and not to mention the regulators and card networks breathing down on your neck pushing for digital transformation, AI adoption, and customer satisfaction.

So, you take the decision to bring Pega’s clear board low code platform to build the solution.

The license can cost anywhere around 1–2 million, which is independent of renewal, on-call support (this is based on how many people you require), and yearly maintenance. And the consultant whom you pay by the hour, recommends a minimal team of 20 Pega developers- a mix of senior, middle, junior, and fresher individuals.

Here’s the break-up of that cost (indicative figures for illustrative purposes only)

And in case, you are unable to build your solution by the time Pega upgrades its software, well then you need to pay an upgrade fee in addition to this $4 million and get your onboarded Pega developers certified to the latest upgrade in order for the software to work. This whole thing will cost you up to $4-$5 million on average.

All these costs are only applicable if you are going for On-prem hosting of Pega. If you are going for the cloud storage option, that’s another expense you have to account for as it is based on the number of users plus the license.

Furthermore, if you are adopting the AI process leg for your digital transformation, this cycle will repeat in addition to the cost mentioned above.

OK, now get to UDM (I can hear you).

Here’s the good news, forget what you read above.

We are a ready-to-go product, not a low-code platform, so none of the above components apply. Our pricing is based on your dispute volume, and we don’t tax you because we have built the product instead of you doing the heavy lifting.

The Role of AI:

I think this would be the shortest paragraph of this whole blog.

If you are building AI using Pega’s low-code platform, let’s say you need to design, build, feed data, train the AI to use that data, and continuously monitor if that AI is evolving in the right way, that suits your needs and the list goes on…..

Oh, I forgot, your Pega developers must complete the AI certification or if not, you need to hire one. So, add that expense to the cost breakup and see the final (hopefully, it is) figure.

And in UDM, our built-in AI will

· Will assign cases based on individual analyst strength.

· Validate the representment documents automatically and suggest the next course of action.

· Most importantly, it will mask sensitive data so that you stay compliant with privacy and data regulations.

And our AI keeps evolving based on the data flowing from your system. So, all you need to do is just kick back and relax.

Now, let’s condense this 1935-word blog into a table, for a quick reference.

If you are looking for a dispute management tool that lets you get started from day one without the burden of developing, look no further, we are here to help!

Just drop your hellos and we’ll bring “Hello Dispute Management” to your bank.