As I have not bought an electronic OSAGO
I think many car owners of habr and geektimes have already heard about the possibility to buy OSAGO electronically. This opportunity appeared about six months ago, I was lucky to try it out for myself just now.
CTP insurance in some regions, such as my Ulyanovsk, generally comes to the absurd - agents sell insurance only with unnecessary pass-through insurance for 1,000–2,000 rubles, and in the insurance companies themselves issue a policy per hour, creating giant lines in which need to borrow in the morning.
Therefore, the ability to buy insurance electronically, without getting up from a chair, looks just like a magical solution to a headache.
')
Looking ahead, I will say that you can issue an eOSAGO only if you previously insured this car in the usual way - the data is checked according to the previous policy.
Recognizing one morning that the insurance is no longer valid today, I decided to try out the new system. This resulted in an epic of three days with enthusiasm and anticipation, hopes and disappointments.
And to be honest, the impression was created that no one has an interest in the quality work of this system.
But first things first.
I chose a couple of large companies that I know of that came across on the first page of the issue on the request of the “electronic insurance system” and went to their sites in search of eOSAGO.
The first thing that turned out - in spite of the declared sales of the electronic OSAGO - companies work with them very limitedly. Rosgosstrakh more than a month ago went to the "technical work". Alfa - insurance - only for those who previously insured them on paper. Some companies provided an opportunity to buy eOSAGO only for those registered in certain regions, mainly Moscow and St. Petersburg, although it would seem that the opportunity to insure electronically should increase the potential client base from the regions of physical presence to the whole country.
Well, okay, I decided, and began to make out.
Then it became clear how the system is not debugged.
The first site that I got is TinkoffStrakhovanie .
Tinkof is famous for the convenience of its online bank, and I expected the same from the insurance interface. But they were surprised. At first, the preliminary amount of insurance for my car and the region for some reason turned out to be two times less than it should be (2,800 rubles instead of 5,500 rubles, as all the other insurance ones expected).
But the convenience of the interface was just "on top". In addition to the fields for entering the address of registration on the passport, for some reason there were required fields for entering the actual residential address. There was not a tick "Use the same data", nor was there a possibility to refuse them. In addition, the same data had to be entered three times - the Insured, the Owner of the car, and finally the Driver.
I filled out the entire data wrapper on the page, clicked "Re-calculate", and ... And nothing, the page hung for 5 minutes. After 5 minutes, an error message appeared suggesting that you contact the nearest office to issue a classic OSAGO, or contact a consultant. The consultant turned out to be an absolutely useless robot - he answered with standard phrases "The electronic CTP is made on the site independently, if you are sure that all the data is filled in correctly, write to the support email address listed on the site." I could not find this email by the way. I asked the consultant - and he disappeared forever.
I was still full of enthusiasm, and decided that everything was just not debugged here, let's go further.
The next insurance was RESO . Here I could not register at the stage of entering the insurer's passport data; they simply did not pass the PCA check. Friends on Twitter wrote that they successfully managed to arrange insurance there by writing to tech support, which suggested that you need to enter "correctly." I wrote to the support service for them, but I didn’t wait for an answer.
Then I went to the VSK website. The interface of this insurance in my opinion the most successful, pleasant and thoughtful. The data are grouped into logical blocks, you do not need to re-enter anything, verification is carried out immediately on the blocks during the filling.
But even here everything was not so good :) I filled in all the data, they successfully passed the verification (!) In PCA. I confirmed the payment via SMS, clicked to pay and got into the purse after the card ... But, after a couple of minutes of waiting, I received a message that “the policy does not pass PCA test” with code 024. If you read, then many people encounter this error.
In the group of geektimes VKontakte appeared such a comment :
If this is true, then in principle it fully explains the artificial restriction of insurance sales.
UralSib on that day did not work the insurance clearance interface at all (and the next day it gave the same error as everyone else).
Having tried all the insurance that I know about that made eOSAGO, I decided to go all the way, and began to try all the insurance contracts in a row, according to the list on the PCA website .
Several insurance interfaces were similar as twins were taken - it turned out that someone had already managed to make a ready-made PolisOffice solution and was selling it for insurance. However, promptly.
At Par-SK for the sale of policies generally used interface 1C 8.3, under the strict guidance of the accompanying instructions, which amused me very much.
The result was the same everywhere - all the data was verified in the PCA database, but they did not pass the verification of the same PCA at the final “clearance” stage of the policy before payment.
It was already late evening, and it was natural to call the insurance ones to no avail. I went through several thematic resources. The number of complaints on the forums created the impression that the electronic policies are selling on the same principle as the paper ones, with the maximum delay of the process - then the policies ended, then the “inspection of the car” line was scheduled for a week. I do not know if this is so. Many wrote that they were helped by an appeal to their insurance with a request to check the data of the policy - according to the data of the previous policy, the data are verified in the PCA. I went to my insurance site and wrote several applications for all possible addresses. At the same time I wrote to several insurance companies, who tried to issue an e-policy, and went to sleep.
Early in the morning I was awakened by a call from my insurance. The caring girl apologized for the inconvenience, checked all the data and sent last year's policy again to the database. According to her, updating the database takes 30 minutes - 3 hours.
Now the testimony of all the insurance has changed - the data have not been checked at the stage of filling the insured's address, some returned a specific code - AddressRSACode. This error was encountered by the other half of users, who did not reach the error at the last stage. Many have tried to write their address with possible errors and typos, and it helped them. But not in my case.
At this stage, I already knew that in the xml that insurance sends to the registry for SOAP, AddressRSACode is a kind of field with a long decimal code similar to the KLADR code.
The address was also chosen by KLADR, and here I had a clue. My address is the avenue of the 50th anniversary of the Komsomol, 24.
In KLADR there is no such house, my house is recorded as 24/20, as it stands at the intersection of two streets. I tried all the options at home (24/20, 24A, etc., 24 building 20), but there was no sense from it. I once again called my insurance, and clarified how they choose a house - from a select or entered manually. The answer was - the street - select with a list of KLADR, the house - manually. I asked to put the house 24/20, as in KLADR, but they refused me, because the passport data of the residence permit costs house 24, and they cannot write another one. Bureaucracy, but fair. All the data in the policy I again rechecked to small letters and sent it again to the database.
As I see it, the problem is how the insurance and the PCA base itself generate this code based on the address. And the way they handle the house number, which is not in KLADR. Apparently in one place from the house number one code is generated, in the other - another. But this is pure speculation.
Of course, it was possible to dig further, making the way to those who developed all this. But it is clear that the insurance will not hire a department to develop such a system, and you can spend more than one week looking for adequate techies from a contractor who will deal with this.
Realizing that the possibilities of insurance in terms of access to the database have been exhausted, I turned directly to PCA. By phone, I did not want to connect me with those who are responsible for IP on OSAGO. Politely explained that the PCA itself does not have “online access” (their expression) to the database. Only insurance can work with the base.
Notice how interesting the approach is - the base operator does not respond to the base, it does not have access to it, and football is far away. That is, for the correctness of the data in the database in the end, no one is directly liable.
Support from insurance companies was also very upset - UralSib and VSK responded with standard replies, saying that if it didn’t work out that way - it means technical difficulties, contact the office. RESO generally just ignored.
ZettaStrakhovaniye was pleasantly distinguished - by request in the private office, the girl called back, who offered to experiment with the address fields, this insurance for me personally remembered for her friendliness (although not a very user-friendly interface).
In the end, I extended my insurance with my insurance. They were tired of correcting the records in the database, and suggested that I extend the policy without waiting in line and inspect the car. The girl and I came and got the policy in 15 minutes. It was the fastest policy execution in the last 3 years.
This time I carefully watched what data the operator saves to the base of the policy. At home, after that I tried again to issue an electronic policy with the same data - it's useless, everything is the same.
Central Bank Position :
In the group of geektimes VKontakte an interesting comment appeared:
CTP insurance in some regions, such as my Ulyanovsk, generally comes to the absurd - agents sell insurance only with unnecessary pass-through insurance for 1,000–2,000 rubles, and in the insurance companies themselves issue a policy per hour, creating giant lines in which need to borrow in the morning.
Therefore, the ability to buy insurance electronically, without getting up from a chair, looks just like a magical solution to a headache.
')
Looking ahead, I will say that you can issue an eOSAGO only if you previously insured this car in the usual way - the data is checked according to the previous policy.
Recognizing one morning that the insurance is no longer valid today, I decided to try out the new system. This resulted in an epic of three days with enthusiasm and anticipation, hopes and disappointments.
And to be honest, the impression was created that no one has an interest in the quality work of this system.
But first things first.
Day 1
I chose a couple of large companies that I know of that came across on the first page of the issue on the request of the “electronic insurance system” and went to their sites in search of eOSAGO.
The first thing that turned out - in spite of the declared sales of the electronic OSAGO - companies work with them very limitedly. Rosgosstrakh more than a month ago went to the "technical work". Alfa - insurance - only for those who previously insured them on paper. Some companies provided an opportunity to buy eOSAGO only for those registered in certain regions, mainly Moscow and St. Petersburg, although it would seem that the opportunity to insure electronically should increase the potential client base from the regions of physical presence to the whole country.
Well, okay, I decided, and began to make out.
Then it became clear how the system is not debugged.
The first site that I got is TinkoffStrakhovanie .
Tinkof is famous for the convenience of its online bank, and I expected the same from the insurance interface. But they were surprised. At first, the preliminary amount of insurance for my car and the region for some reason turned out to be two times less than it should be (2,800 rubles instead of 5,500 rubles, as all the other insurance ones expected).
But the convenience of the interface was just "on top". In addition to the fields for entering the address of registration on the passport, for some reason there were required fields for entering the actual residential address. There was not a tick "Use the same data", nor was there a possibility to refuse them. In addition, the same data had to be entered three times - the Insured, the Owner of the car, and finally the Driver.
I filled out the entire data wrapper on the page, clicked "Re-calculate", and ... And nothing, the page hung for 5 minutes. After 5 minutes, an error message appeared suggesting that you contact the nearest office to issue a classic OSAGO, or contact a consultant. The consultant turned out to be an absolutely useless robot - he answered with standard phrases "The electronic CTP is made on the site independently, if you are sure that all the data is filled in correctly, write to the support email address listed on the site." I could not find this email by the way. I asked the consultant - and he disappeared forever.
I was still full of enthusiasm, and decided that everything was just not debugged here, let's go further.
The next insurance was RESO . Here I could not register at the stage of entering the insurer's passport data; they simply did not pass the PCA check. Friends on Twitter wrote that they successfully managed to arrange insurance there by writing to tech support, which suggested that you need to enter "correctly." I wrote to the support service for them, but I didn’t wait for an answer.
Then I went to the VSK website. The interface of this insurance in my opinion the most successful, pleasant and thoughtful. The data are grouped into logical blocks, you do not need to re-enter anything, verification is carried out immediately on the blocks during the filling.
But even here everything was not so good :) I filled in all the data, they successfully passed the verification (!) In PCA. I confirmed the payment via SMS, clicked to pay and got into the purse after the card ... But, after a couple of minutes of waiting, I received a message that “the policy does not pass PCA test” with code 024. If you read, then many people encounter this error.
In the group of geektimes VKontakte appeared such a comment :
Hmm, but I know what mistakes he caught there. The latter was associated with the back number of the policy in the database. And the first was an error sending data to the PCA (intentional by the UK).
If this is true, then in principle it fully explains the artificial restriction of insurance sales.
UralSib on that day did not work the insurance clearance interface at all (and the next day it gave the same error as everyone else).
Having tried all the insurance that I know about that made eOSAGO, I decided to go all the way, and began to try all the insurance contracts in a row, according to the list on the PCA website .
Several insurance interfaces were similar as twins were taken - it turned out that someone had already managed to make a ready-made PolisOffice solution and was selling it for insurance. However, promptly.
At Par-SK for the sale of policies generally used interface 1C 8.3, under the strict guidance of the accompanying instructions, which amused me very much.
The result was the same everywhere - all the data was verified in the PCA database, but they did not pass the verification of the same PCA at the final “clearance” stage of the policy before payment.
It was already late evening, and it was natural to call the insurance ones to no avail. I went through several thematic resources. The number of complaints on the forums created the impression that the electronic policies are selling on the same principle as the paper ones, with the maximum delay of the process - then the policies ended, then the “inspection of the car” line was scheduled for a week. I do not know if this is so. Many wrote that they were helped by an appeal to their insurance with a request to check the data of the policy - according to the data of the previous policy, the data are verified in the PCA. I went to my insurance site and wrote several applications for all possible addresses. At the same time I wrote to several insurance companies, who tried to issue an e-policy, and went to sleep.
Day 2
Early in the morning I was awakened by a call from my insurance. The caring girl apologized for the inconvenience, checked all the data and sent last year's policy again to the database. According to her, updating the database takes 30 minutes - 3 hours.
Now the testimony of all the insurance has changed - the data have not been checked at the stage of filling the insured's address, some returned a specific code - AddressRSACode. This error was encountered by the other half of users, who did not reach the error at the last stage. Many have tried to write their address with possible errors and typos, and it helped them. But not in my case.
At this stage, I already knew that in the xml that insurance sends to the registry for SOAP, AddressRSACode is a kind of field with a long decimal code similar to the KLADR code.
The address was also chosen by KLADR, and here I had a clue. My address is the avenue of the 50th anniversary of the Komsomol, 24.
In KLADR there is no such house, my house is recorded as 24/20, as it stands at the intersection of two streets. I tried all the options at home (24/20, 24A, etc., 24 building 20), but there was no sense from it. I once again called my insurance, and clarified how they choose a house - from a select or entered manually. The answer was - the street - select with a list of KLADR, the house - manually. I asked to put the house 24/20, as in KLADR, but they refused me, because the passport data of the residence permit costs house 24, and they cannot write another one. Bureaucracy, but fair. All the data in the policy I again rechecked to small letters and sent it again to the database.
As I see it, the problem is how the insurance and the PCA base itself generate this code based on the address. And the way they handle the house number, which is not in KLADR. Apparently in one place from the house number one code is generated, in the other - another. But this is pure speculation.
Of course, it was possible to dig further, making the way to those who developed all this. But it is clear that the insurance will not hire a department to develop such a system, and you can spend more than one week looking for adequate techies from a contractor who will deal with this.
Realizing that the possibilities of insurance in terms of access to the database have been exhausted, I turned directly to PCA. By phone, I did not want to connect me with those who are responsible for IP on OSAGO. Politely explained that the PCA itself does not have “online access” (their expression) to the database. Only insurance can work with the base.
Notice how interesting the approach is - the base operator does not respond to the base, it does not have access to it, and football is far away. That is, for the correctness of the data in the database in the end, no one is directly liable.
Support from insurance companies was also very upset - UralSib and VSK responded with standard replies, saying that if it didn’t work out that way - it means technical difficulties, contact the office. RESO generally just ignored.
ZettaStrakhovaniye was pleasantly distinguished - by request in the private office, the girl called back, who offered to experiment with the address fields, this insurance for me personally remembered for her friendliness (although not a very user-friendly interface).
Day 3
In the end, I extended my insurance with my insurance. They were tired of correcting the records in the database, and suggested that I extend the policy without waiting in line and inspect the car. The girl and I came and got the policy in 15 minutes. It was the fastest policy execution in the last 3 years.
This time I carefully watched what data the operator saves to the base of the policy. At home, after that I tried again to issue an electronic policy with the same data - it's useless, everything is the same.
upd
Central Bank Position :
Shvetsov said that the Bank of Russia plans to adjust the current legislation. “We want to oblige to sell policies in remote format in an unconditional order. It will not be the choice of the insurance company, but an obligation, ”the official said.
upd2
In the group of geektimes VKontakte an interesting comment appeared:
Hmm, but I know what mistakes he caught there. The latter was associated with the back number of the policy in the database. And the first was an error sending data to the PCA (intentional by the UK).
Source: https://habr.com/ru/post/394437/
All Articles