- Case Number: a20100213.1
- Status: Closed
- Claimants: Nikolas P
- Respondents: Francois C
Initial Case Manager: UlrichSchroeter
Case Manager: SebastianKueppers
Arbitrator: UlrichSchroeter
- Date of arbitration start: 2011-02-27
- Date of ruling: 2011-03-15
- Case closed: 2011-03-15
- Complaint: Dispute due to difference in the name on the CAP form and the system
- Relief: TBD
Before: Arbitrator UlrichSchroeter (A), Respondent: Francois C (R), Claimant: Nikolas P (C) Case: a20100213.1
History Log
- 2010-02-13 (issus.c.o) case [s20100213.111] + [s20100214.15]
- 2010-02-14 (iCM): added to wiki, request for CM / A
- 2011-02-24 (A): I'll take care about this case as (A)
- 2011-02-24 (CM): appointed by (A)
- 2011-02-24 (A): moved (C2) to (R) for correction
- 2011-02-24 (A): sending init mailing with CCA/DRP acceptance request to (C), (R)
- 2011-02-24 (A): req to (Support): 1. Full name listed, 2. Assurances rcvd, 3. Assurances given from user accoount (R)
- 2011-02-24 (C): accepts CCA/DRP, sends PoV
- 2011-02-25 (Support): [s20110224.16] sent requested infos
- 2011-02-27 (R): accepts CCA/DRP, sends PoV
- 2011-02-28 (A): requesting full name of (R) from (AS1) from his CAP form
- 2011-02-28 (A): requesting one IDdoc scan from (R)
2011-02-28 (A): req to (R): how many assurances (R) got at Fosdem 2010 ?
- 2011-02-28 (AS1): responded
- 2011-02-28 (A): question regarding addtl. handwritten notes onto the CAP form about addtl. names to (AS1)
- 2011-02-28 (R): one addtl. assurance by (AS2)
- 2011-02-28 (R): sent IDdoc scan
- 2011-02-28 (AS1): sends CAP form scan
- 2011-03-04 (A): requesting CAP form scan from (AS2), Assurance not yet entered into the online system
- 2011-03-11 (A): clarification and summarize of current progress state, with 2 options possible to proceed. Request for decision by (R)
- 2011-03-11 (AS3): showed original CAP form in F2F meeting
- 2011-03-15 (R): accepts option a), names w/o middlenames
Original Dispute, Discovery (Private Part)
Link to Arbitration case a20100213.1 (Private Part)
EOT Private Part
Discovery
- related policies
PracticeOnNames (last updated 2011-02-13)
- 2011-02-25 (Support): [s20110224.16] sent requested infos
- full name entered into the account (Givenname, Middlenames, Lastname)
- 1 assurances received, (AS1)
Assurer
Assurers Name
Conformant to FULL name
AS1
Hendrik L
{0}
Potentialy other Assurances at Fosdem 2010 ?
Assurer
Assurers Name
Conformant to GN + SN
Conformant to FULL name
Givenname
Middlename(s)
Surname
Acceptable?
C
Nikolas P
{+}
{-}
{+}
{-}
{+}
{-} missing Middlename(s)
AS1
Hendrik L
{+}
{-}
{+}
{-}
{+}
{-} missing Middlename(s)
AS2
Dirk A
{+}
{+}
{+}
{+}
{+}
{-} other causes
Ruling
Despite the fact, that one Assurer verified (R)'s Middlenames in his online account and an ID doc scan shows (R)'s Middlenames on it, the potential Assurers who did enter their Assurance onto (R)'s online account causes problems, to be unverified. The default next step will be, to revoke the assurances. But this will decreases (R)'s account from state Assured back to Unassured. This is unacceptable for (R).
- Discovery determined, we have a case of avoidable errors by Assurers here, by not adding a note of addtl. Middlenames they've probably seen in (R)'s IDdoxs, but this doesn't helps to solve this current case.
- So (R) has two options:
- search for addtl. Assurers who can verify the Middlenames and giving Assurance points -or-
- removal of Middlenames in (R)'s account, so the existing assurances are in compliance with the policies.
The simple, strict rule from Assurance Handbook and PracticeOnNames allows reduction of informations (removal of Middlenames), but prevents addition of infomations (keep the Middlenames in the Account)
- (R) accepted removal of Middlenames
- So therefor I order (Support) to remove the Middlenames in (R)'s account
- Further I rule, that the Assurers who entered Assurances onto the Online account w/o having the Middlenames on the CAP should get an advice on how to continue with differences between CAP form informations and informations found in Online Account by an Assuree. No further actions to take over the affected assurers.
- Further I rule, that the Assurers who didn't made a note onto their CAP forms about addtl. names seen in an Assuree's IDdoxs to get an advice, how they'll can bring evidence into the Assurance process, by adding addtl. informations presented in the F2F meeting. No further actions to take over the affected assurers.
The avoidable errors by Assurers topic had been added yet onto the ATE presentations material, but not all Assurers yet attended an ATE.
Apologies to (R), that we cannot pass this case with addtl. Middlenames left in online account, caused by avoidable errors by Assurers. We continue to share the informations to the Assurers to bring evidence in an Assurance process.
Frankfurt/Main, 2011-03-15
Execution
- 2011-03-15 (A): sending ruling to (C), (R), (AS1), (AS2)
- 2011-03-15 (A): exec request to (Support) for removal of Middlenames in (R)'s account
- 2011-03-15 (A): sending Assurers Advise I to (AS1)
- 2011-03-15 (Support): [s20110315.26] I ececuted the ruling and removed the middlenames out of the account of (R)
- 2011-03-15 (A): sending Assurers Advise II to (C), (AS1)
- 2011-03-15 (A): exec report, final notification to (C), (R), (AS1), (AS2). Case closed.
Similiar Cases