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 that in the morning that insurance is no longer valid today, I decided to try out a 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 came across is TinkoffStrakhovanie .
Tinkof is famous for the convenience of its Internet 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 policyholder, the owner of the car, and finally the driver.
I filled out the entire data bag on the page, clicked "Re-calculate", and ... And nothing, the page hung for 5 minutes. After 5 minutes, an error message appeared suggesting you to contact your nearest office to issue a classic CTP, 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 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 I 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 passport data of the insured, 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 never got 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.
In UralSiba I did not work insurance registration interface that day (and the next day he gave the same mistake as everyone else).
Having tried all the insurance that I know about that are doing 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-SKfor the sale of policies in general, the 1C 8.3 interface was used, under the strict guidance of the accompanying instructions, which amused me a lot.
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 stage of the final “clearance” 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 e-policies are selling on the same principle as paper ones, with the maximum delay of the process - then the policies have expired, then the queue “for car inspection” is 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 policy data - 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. In her words, 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 got a clue. My address is the avenue of the 50th anniversary of the Komsomol, 24.
There is no such house in KLADR, 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 I was refused, because there is a house 24 in the passport data of registration, and they cannot write another one. Bureaucracy, but fair. All the data in the policy I once 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 insurance will not hire a department to develop such a system, and you can spend more than one week looking for adequate technicians 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 what an interesting 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.
ZettaInsurance was pleasantly distinguished - by request in the private office the girl called back, who offered to experiment with the address fields, for me personally, this insurance was remembered for its friendliness (although not a very user-friendly interface).
As a result, I extended the 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 that in the morning that insurance is no longer valid today, I decided to try out a 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 came across is TinkoffStrakhovanie .
Tinkof is famous for the convenience of its Internet 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 policyholder, the owner of the car, and finally the driver.
I filled out the entire data bag on the page, clicked "Re-calculate", and ... And nothing, the page hung for 5 minutes. After 5 minutes, an error message appeared suggesting you to contact your nearest office to issue a classic CTP, 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 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 I 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 passport data of the insured, 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 never got 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.
In UralSiba I did not work insurance registration interface that day (and the next day he gave the same mistake as everyone else).
Having tried all the insurance that I know about that are doing 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-SKfor the sale of policies in general, the 1C 8.3 interface was used, under the strict guidance of the accompanying instructions, which amused me a lot.
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 stage of the final “clearance” 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 e-policies are selling on the same principle as paper ones, with the maximum delay of the process - then the policies have expired, then the queue “for car inspection” is 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 policy data - 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. In her words, 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 got a clue. My address is the avenue of the 50th anniversary of the Komsomol, 24.
There is no such house in KLADR, 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 I was refused, because there is a house 24 in the passport data of registration, and they cannot write another one. Bureaucracy, but fair. All the data in the policy I once 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 insurance will not hire a department to develop such a system, and you can spend more than one week looking for adequate technicians 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 what an interesting 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.
ZettaInsurance was pleasantly distinguished - by request in the private office the girl called back, who offered to experiment with the address fields, for me personally, this insurance was remembered for its friendliness (although not a very user-friendly interface).
Day 3
As a result, I extended the 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 a 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).
Only registered users can participate in the survey. Sign in , please.