Customer Relationship/Account

Topics: ACORD XML 2.x, General
Developer
Jun 3, 2016 at 2:01 PM
In regard to the Account/Party modeling discussion yesterday on the 2.0 WG call, we should leverage and utilize the ACORD Information Model (AIM) to guide our decision making. As I pointed out on the call, we should be utilizing the same concepts and names across our domain to create a ubiquitous language. Having different language and different concepts across ACORD communities does not help our cause. It's been a longstanding frustration of mine that ACORD forms are different than ACORD XML which is different than AL3, etc. Perpetuating these silos makes our job more difficult.

At Boston Software, we've been utilizing AIM and implementing based on it for about a year now which is why I have this stuff in my head. I'm not exactly sure what Jamie means when he was discussing the concept of an Account. Because of his reference to CRM software, it is my impression that Jamie is thinking of the Customer Relationship, the Customers, and the Agreements associated with the relationship. Jamie, please clarify if I've misconstrued your thoughts. If I'm correct though, then the usage of the term Account is not the correct model based on AIM.

Here is a (simplified) point of reference from AIM:

Party is a Person or an Organization.
Parties play roles - PartyRole subtypes - such as Customer, Driver, Insured, Insurer, etc.
Relationships can link parties and agreements together. e.g CustomerRelationship has one or more Customer role players, ServiceProvider role player, and an Agreement can be linked to this relationship.
A policy is an Agreement with a specific subtype of InsuranceAgreement.
Account - accounting specific.
Account Agreement - financial services derivative such as bank, credit card, etc. This is a sibling (in the class hierarchy) of an Insurance Agreement -both of which inherit Financial Services agreement.

Definitions of Account and Account Agreement from AIM and the Business Glossary:

Account - Accounts are logical or physical concepts for holding similar "things" (e.g., money, policies) that can be managed. This type of Account is used for accounting purposes only. See [AccountAgreement] for an account that is a type of financial services agreement.

Account Agreement - An agreement between a financial services provider and an account holder related to the management of a financial account.
Developer
Jun 5, 2016 at 1:49 PM
First... Danny said,
"As I pointed out on the call, we should be utilizing the same concepts and names across our domain to create a ubiquitous language. Having different language and different concepts across ACORD communities does not help our cause. It's been a longstanding frustration of mine that ACORD forms are different than ACORD XML which is different than AL3, etc. Perpetuating these silos makes our job more difficult." I wholeheartedly second Danny's comment.

This goes to the heart of why the Framework group work is not useful at this time.

We need ACORD Model/XML 3.0! Where Message, Form, Product, etc inherit from Model. Having the messages derive the standard is like the tail wagging the dog, but, in the lack of leadership and participation by the Framework group on this point, this is exactly what is happening. The messages are the outward carrier/vendor face of ACORD's non-compliant model, and why traction is gaining steam there.

Several large carriers have stated to me privately that they use a personalized form of the messages, but cannot use the model because it doesn't sync with message/forms.

Second,
Accounts have a relationship to Party, and as Danny points out, not a Party. Party is one of the top level components. It is a carrier, vendor, insured, prospect, underwriter, adjuster, reinsurer, MGA, agent, employee, lienholder, cert holder, regulatory body, etc. Only some of which have an Account.
Coordinator
Jun 5, 2016 at 7:05 PM
Edited Jun 16, 2016 at 5:25 PM
Here's a first pass at creating an AccountRq message. I simply added the following reusable aggregates to a new entity:

  • MiscParty
  • Location
  • BusinessInfo
  • PartialPolicy
  • Producer
  • BillingActivityInfo
  • InstallmentInfo
  • Loss
<AccountRq>
    <RqUID>00000000-0000-0000-0000-000000000000</RqUID>
    <TransactionRequestDt>2001-12-17T09:30:47.0Z</TransactionRequestDt>
    <TransactionEffectiveDt>2001-12-17T09:30:47.0Z</TransactionEffectiveDt>
    <BusinessPurposeTypeCd>NBS</BusinessPurposeTypeCd>
    <ItemIdInfo>
        <AgencyId>123</AgencyId>
        <InsurerId>A456</InsurerId>
    </ItemIdInfo>
    <AccountStatusCd>String</AccountStatusCd>
    <AccountNumber>String</AccountNumber>
    <MiscParty/>
    <Location/>
    <PartialPolicy/>
    <Producer/>
    <InstallmentInfo/>
    <BillingActivityInfo/>
    <BusinessInfo/>
    <Loss/>
</AccountRq>