EDI PROP Message.


Overview

With software systems in insurance brokers, price comparison site and insurers all being different back it was decided back in the late 1980s that a standard way of communicating between them was needed and was created, Brokernet.

Much of what was agreed then is still in use today because it works and changing it would be expensive and for little benefit.

However like all standards they are also restrictive, it is very difficult to create a radically different motor insurance policy because so many parties would have to agree on modifying the standards and their systems.

Although multi car insurance may sound new, it was catered for in the original standards, what was not catered for was a combined car/household insurance policy so implementing this would be a significant development.

However the Internet has allowed insurers to interact directly with customers, so while creating a combined car/household policy and selling it via a broker would be a huge project creating one on their own web site would not.


EDI PROP05:2 Message

STX=ANA:1+0000:UnknownFrom+00001:UnknownUnto+072420:112738+000001++PROP05'
MHD=1+PROP05:2'
CID=A00000:UnkownFrom+A00001:UnkownTo'
SFI=0:WebSite:1.0:18052019:18052019'
SFT=1'
PLH=PN0000001+NPE:00:NPE:00+WS+24072020:120000+24072021:115959+123123++10000+40818961+Sch001+Auth001'
PYD=SF:CA+25002++22443++++++++23811'
This message is created using a very rigid format the + and : are field separators and the ' the end of line marker.

The + separates fields that must be present even if they have no values, hence the long string of them, this is necessary as all fields are defined by their position.

The : separates fields that are optional.

The MHD segment says what the message is, in this case the 1 is a sequence number of the message in the file, PROP05 means a new business message and the 2 is the variant of that message.

The PYD segment is payment details and each position's meaning is shown in the table.

Just to stress the point the meaning of a value is entirely depended upon where it appears, so both sides the sender and the receiver agree to this outside of the actual message.

Not only do both parties have to agree the position they also have to agree the format, for example PPCB is S9(8)V99.

You may notice that the fields from RTPA don't appear in the message above, it is allowed to end a segment early and all missing elements are assumed to be empty.
STX= - Start of Transmission
MHD= - Message Header
CID= - Communicators ID
SFI= - Software Identifier
SFT= - Software Identifier Trailer (count of SFIs) 
PLH= - Policy Header
PYD= - Payment Details
A full message consists of a lot more segments laid out like those shown.
Item Name Meaning
PYD Segment name
= Fixed format constant character
SF PCMI Type Of Payment Payment Collection Method By Insurer Type SF = Single payment in full
CA PCMI Type Of Payment Payment Collection Method By Insurer Method CA = Cash
25002 PPCB Policy Premium - Calculated by Broker
PPPB Policy Premium - Policyholder to Broker
22443 PPBI Policy Premium - Broker To Insurer
BRFE Broker Fee
DPST Deposit
INSC Instalment Scheme Type
INAM Instalment Amount
INNO Number Of Instalments
INND Date Of Next Instalment
CATP Credit Agreement Signed on Trade Premises
23811 ANPS Annual Premium Calculated by Sender
RTPA Reduced Term Premium Adjustment
PCMB Payment Collection Method By Broker
SVCH Service Charge


XML Instead Of EDIFACT PROP.

A lot of people may now be screaming just use XML it is more flexible, superficially this is true but in reality it isn't.

The web has created a whole generation or even two of developers who have been brought up with if it works 95% of the time then that's the best we can hope for, unfortunately that is not good enough for insurance or banking,

The problem xml has is that while it is very easy to change a message it is much more complicated to process the changed message throughout systems controlled by various parties.

For example one insurer decides that it is important to know if the proposer is a pet owner as they want to offer a discount if he is.

They go to a price comparison site who agrees to add this question, the other sites are not asked nor the suppliers to high street brokers.

So all the other insurers would not be aware of this new XML Schema and would not have altered and tested their systems to support the has a pet question.

A hobbyist world would propably just say ignore the unknown bit about the pet but you can't do this in a system forming potentially very high value liabilities.

You can't just send the new message and expect all insurers to process it, even though it doesn't matter that they are not interested in the new question, because they need to test the new message to be sure that it still works with their systems.

As this is a cost with no benefit to them they won't do it.

After all if you don't know why there is a new message format then you don't know that the change doesn't matter to you, the new message may have contained something that you care about or the unexpected element may be indicative of an error.

So the new message would have to be sent only between these two parties.

If one insurers comes to one private agreement with one platform then fine, but once 20 insurers come to 15 different agreements with 25 providers developing and testing all of the message formats becomes unmanageable.

It is not the format that is the problem, it would be easy to invent a private PET=Y; segment in the existing EDI structure it's the fact that you need many parties to agree to handle multiple message formats.
Original message
<motorproposal>
    <driverdetails>
        <driver1>
            <name>Mr Ian Smith</name>
        </driver1>
    </driverdetails>
    <vehicledetails>
        <vehiclecode>53579303</vehiclecode>
    </vehicledetails>
</motorproposal>
could easily be changed to the xml message and its associated schema to one that supported the new question.
<motorproposal>
    <driverdetails>
        <driver1>
            <name>Mr Ian Smith</name>
            <isapetowner>true</isapetowner>
        <driver1>
    </driverdetails>
    <vehicledetails>
        <vehiclecode>53579303</vehiclecode>
    </vehicledetails>
</motorproposal>


These Could Be Advertising Links
"Antique" Computer Insurance
Some 5 1/2 floppy discsAlthough technically pretty close to useless old computer equipment is very difficult to replace as it mostly ended up in the skip.

Insure it with us and we can fund the replacement of your MK-14 or Jupiter Ace.
Beer Insurance
Beer glass Many cask ale pubs find that business profitability is affected by poor quality ale.

Once the barrel is open and half sold you can't send it back and it starts to go off after a a few days.

We offer Poor Selling Beer Insurance allowing you to dispose of bad beer and retain your reputation.
Spaceship Insurance
Minbari spaceship from B5 Despite CGI taking over special effects many models are still produced and then scanned. These models are close to irreplaceable as model makers are rare and heavily booked up.

We are the UK's major insurer of movie props.
Please note that the links shown above may use tracking cookies or similar technology. Tick here to give consent or confirm when asked, if you are not asked then tracking is not being used.