Share to:

Posted: 11 March 2021

ERGO Hestia Pilots Digital DLT for Policyholder Refund Payments



An Interview with Oskar Jedynasty, Head of Automation, IT Department for ERGO Hestia

ERGO Hestia, a member of ERGO Group and the second largest insurance company in Poland, recently completed a pilot of Billon Group’s breakthrough new DLT payout system. They set out to make refunds for unused policies faster and smoother both on the company and customers end and provide significant savings in the process after full rollout. How did it go? 

To find out, Full Tilt Consulting’s Lisa Tilt and Nancy Broe spoke with interviewed Oskar Jedynasty, ERGO Hestia’s Head of Automation, IT Department, about the project.  Below are excerpts from the conversation.


ERGO Hestia: Top P&C and life Insurer in Poland
Case Study:  Cut costs, streamline  payment process -- and increase payment completion rate -- for required refunds for early termination car insurance policies
Problem: Required a more efficient and cost-effective alternative to  call centers and mail to provide refunds to customers. Needed to overcome obstacles and build trust while gathering payment details from clients. Desired a competitive, peer-to-peer system with strong beneficiary verification controls.
Solution: A white-labeled payout solution using Billon Solutions’ regulated DLT digital currency system  under an EU e-money license expedited payments using text messages.


      • 30% cost savings on end-to-end process

      • Client can successfully collect money without the help of call center

        • Payout collection digitally linked to identity

        • No fumbling to find information; clients respond when convenient

        • Tailored user experience: fully branded as ERGO Hestia; clients can call insurer and validate source is trustworthy

      • DLT settlement is instant; reducing costs and time needed for exception handling and operations

      • Reduces operational risks; process more secure for insurer and client; AML and KYC procedures are embedded in the DLT; private data is hidden by encryption



Welcome, Oskar.  Can you give us an overview of the problem you faced?

We had an expensive process for returning overpaid premiums to our clients. The most common scenario for this is when our clients, especially offline ones, buy the policy in an agency. They purchase motor third party liability, and some additional products like motor accident insurance. If they later sell the vehicle, the motor TPL is transferred to the new owner of the vehicle. (In Poland we do not insure the driver, but the third party liability is on the vehicle.) By law, we need to transfer motor TPL -- but we cannot automatically transfer any other risks. 

So in many cases, we have three or four months of unused accident insurance and we have to return the premium for unused periods. It's mostly a very small amount of money, like £10 or even less. We do not know the customer's bank account number, because they don’t provide it when they buy a policy in the agency. They pay either cash or via the post office.

We are left with a problem: we need to return the money and we don't know how. 

We only have the client’s phone number and sometimes their address. We could send cash via postal services, but the cost is huge. It can be even 50% of the amount that we have to return.  If we have to return £10, we might have to pay £5 in service fees. This process is also time-consuming: postal transfer takes time, sometimes people do not collect the money, they are not at home or we do not have their current address. 

We could also call the client, ask for their bank account number and then perform a regular wire transfer. But that is  also not efficient, because we have to pay consultants to perform those calls. It takes some time. And if our client is not able to provide the bank account number at the agency, they also are not likely to give it to us during the phone call, because nobody knows the bank account number by heart.

We've been calling clients for a couple of years, but the effects were not satisfactory. It took from two to three phones to collect bank account numbers. If we calculate the money we had to spend on those goals and to pay our consultants, it was quite an expensive process. 

Fortunately we met Billon, which has an e-money license and is approved by the Polish financial authority to perform money transfers directly to the phone number. 

We performed a PoC on a group of clients, sending them SMS messages with a link where clients could directly redeem the money. Some of them were even those customers we had previously asked for a bank account number and were not able to provide us with those details. Once they got an SMS message many of them took the money from Billon. It was very quick. Eighty or 90% of those who collected the money performed the action within 24 hours. Also it is cost-effective because it's much cheaper to send SMS messages via Billon than sending a postal carrier. 

Our goal is to have 50% of people who received the SMS message collect the payment. Currently the level is slightly lower, because on our end we haven’t yet automated the process optimally and the delay between selling the vehicle and the SMS message with the overpayment is too long. If we can shorten it -- and I'm pretty sure we'll do it next year -- we would achieve or even exceed 50%. With Billon we can also address some other cases, especially when it comes to multiple, concurrent small payments.


Can you expand on that? When you say 50%, is that because of the automation between the tool and the policy admin system?

Mostly because of that. We know that reaching 100% is simply impossible, because some clients never respond no matter what we do. Currently it is below 50%, because the time between when we generate the report with payment recipients and send it to Billon is slightly too long. If we can shorten it and introduce triggers -- such as when we receive the information about the change of the vehicle owner --  I think we'll increase the level of received transfers.


How about the setup? How complex was it for you to get this running smoothly? 

To be honest the entry level is low;  we didn't have to put in much effort. We could start using it the next day after we signed the agreement with Billon. 

There are a few options we can use:

  1. We can manually enter the details of the recipients and the amount of the money that should be sent to them. 

  2. We can use flat files like CSV files to take the report from one system, prepare a check and send it to Billon, and then take it back and change the status of the payments in our systems appropriately. 

  3. The third way is to utilize REST API -- which we haven’t done yet, but we checked the documentation of the API and it looks promising. I think it would be easy to use, but we wanted to start as soon as possible since we had thousands of clients waiting for their payment. 

So we started with the flat files and we didn't want to wait for our IT team to take care of the API integration. This is something that we plan for 2021.

When your clients receive the SMS message they click on, what happens next? What's their experience?

They are transferred to a webpage where they confirm their phone number. Then they receive another message with a one-time code that is valid for three minutes. They need to enter this one-time code again on the webpage, and then they see the list of the payments that were sent to them. They can click and decide where the money should go, for example, provide the bank account number. 

But the difference between this approach and calling the client is that the client can click the link anytime they want. So if it's convenient for them to click it later or when they can check the actual account number, they can do that at their convenience. That's why it works better than calling and asking for a bank account number.


What percentage cost savings do you expect from this?

Everything depends on the scale, because we are still working on the final quotation with Billon. We are on a good track.  It will be the fixed cost of utilizing the platform and the cost per transaction. Naturally, if there were just a few transactions, then the cost would be higher, and this solution would not make sense. But with 1,000 or 2,000 or 5000 transactions each month, when we can lower the cost of the process by 50% or even more, it makes perfect sense.


You mentioned that in the past you have tried hiring consultants to call policyholders about their refund.  How much did you limit that spend with the introduction of this system?


I don't have this estimation, especially because we are in the first phase focusing on those customers who did not provide us with the bank account number, even if some of them were called before by the consultants. But I'm pretty sure that without telling any percentage points it's more efficient to send SMS messages using the Billon solution than to perform a call. Every call takes a couple of minutes and the consultant who receives the bank account number also needs to validate the number, put it in the system, etc. So it takes the consultant’s time and at least a couple of zlotys per transaction -- more than a successful transaction with Billon. 

I think our goal would be to choose Billon as a first option to all of those transactions where we do not have a bank account number. If we have a bank account number then the wire transfer probably would be more efficient. But for the rest, I think the first step should be to try to send money via Billon and just for the remaining part consider calling or sending cash via postal services.


When you speak of a success rate of about 50%, is that because some people did not respond to consultants’ calls and just don't respond at all?

Some of them, yes. But still, if we use other channels, we never achieve 100%. That's the way it works. We also need to remember that we are not talking about huge returns. So if the client has to put some effort in the process, even if it's like two minutes or one minute, and they know that they can get just £3 in return, some of them postpone it for later and never come back. 

If we would send higher returns, probably the percentage would be also higher. When we tried to get the bank account number from clients, they were stating "we'll get back to you" but they never called us back, because it was too much effort to receive these two or three pounds. But for us it is a problem because we are still obliged to return this money, or at least to perform a couple of attempts.


What has the reaction been from your customers on the receiving end?

We were afraid that our clients would treat this as a phishing attempt or something similar. It's not common that you receive SMS messages with information that some money was sent to your phone number. Fortunately those risks didn't materialize. 

We had a couple of calls when clients just called us and asked, if it is real, but we didn't receive any negative reactions. Some clients even praised us that it was easy for them to use. So we were afraid of the clients’ reaction but did not encounter any serious issues.


Have you seen any additional benefits, like bank reconciliations being cleaner or processes getting smoother?

The process is indeed getting smoother! We prefer to make those settlements as quickly as we can. If we still have thousandsof clients to whom we owe some money, it makes other processes more complicated on our end. The sooner we push this money back to the client, the better. 

And for this purpose, when we do not have a bank account number, Billon is quicker than alternatives, because 80-90% of clients who actually click "Collect the money", do so within 24 hours. 

With the postal services we have to wait for the information for, let's say, two weeks. 


What risks did you consider as you approached this project?

We perform risk analysis for every single project. Bear in mind that for this project we wanted to return overpaid premiums which, as I mentioned, are a very small amount of money per client. So the risk was also low, even if one client out of a thousand provided a bad phone number and the verification process didn't work well. In that case the risk was that someone would ask us to send those £10 via different channels. 

If you were to transfer higher amounts or pay the big claims through this channel, the risks would be on a different level. But this is not something we're really looking at the moment. If we have the phone numbers that were previously confirmed by the clients or by our agents, the risk of sending money to someone that should not receive them is lower. So I think it's not an issue. 

Also all the AML procedures are in place on the Billon site. This is something that we found as a benefit of using the Billon solution. 

We were slightly afraid of some reputational risks, because we didn't know how the market would respond to the information that we started to send the money using blockchain, as blockchain could be understood as bitcoin or something suspicious. But instead of reputational risk, we found that the press and the media reacted positively seeing an insurance company that uses new safe technologies. This risk also did not materialize. 


Phishing often goes out by text.h How do you get a customer comfortable that what they receive is a genuine text message and not a scam?

We have embedded the Billon solution in our company domain. So we do not transfer people to other domains, they're being transferred to our domain, secured by SSL and we do not use any link shorteners. Clients can see that they're staying within our environment. So I think that was one of the most important reasons. 

The second thing was that it was branded with ERGO Hestia. The overall look of the payment panel included our logo, colors, etc., so clients didn't have too many doubts about it. In the SMS message we also provided a phone number to our helpdesk. 

When in doubt, clients could always call and hear that this is our official line and that we started to use a new channel to send money back to the clients. So no link shorteners, our domain, our branding, and we didn't really have those issues.


Did you include a clause in your policies letting your clients know this is how funds would be returned?

We did not put any information in the policies document that we can send some money back via Billon, because when those policies were issued we didn't even know that we would be using that solution. We put some information on our webpage and secured some media coverage to make people aware of this fact. Also we sent information to all of our intermediaries that if any of their clients asks them if they know something about those returns, they can confirm that it's a genuine and safe process that they can surely use.


Did you track clients who did not collect the money?

We did some statistics in the middle of the proof of concept. There was a very small chunk of customers who clicked on the link and did not finish the process probably due to bad timing.


Your success is amazing and we thank you for your time!  Can you offer a final comment on other use cases are you looking at? 

ERGO Hestia is always looking for innovation to improve our client and employee experiences.   

And of course we are always looking for operational improvements in all our lines of business.   Blockchain is one of many technologies of interest, and we are excited about our early results and to be able to find firms like Billon who understand the needs of regulated businesses like ours.  




Lisa Tilt
Founder & CEO, Full Tilt
Lisa Tilt is founder and CEO of Full Tilt, a marketing communications consultancy focused on distilling brand position for momentum organizations and constructing methods to connect with their essential stakeholders. Nancy Broe is vice president of Full Tilt and a strategic communications advisor to clients in technology, energy, and other disruptive industries.



They trust us











Continue the conversation


Do you want to learn more about Billon and our enterprise DLT system? Get in touch!






Share to: