Case management

System assessment

Based on the RBA rating, the system makes an assessment on the risk of the dossier.

Example mapping

RBA rating	RBA system assessment
LOW	OK
MEDIUM	NOK
HIGH	NOK

Example process

• Create dossier
  • DD checks
  • DD aggregation
  • RBA calculate
  • RBA assessment by system based on RBA rating
    • Example:
      • If rating == LOW → systemAssessment: OK
      • If rating > LOW → systemAssessment: NOK

Manual risk assessment

The system assessment can be overruled by a user

Dossier in SUBMITTED status have assessment: REJECTED. It should still be possible to accept these dossiers:

• Investigate DD
  • Case 1: DD contains false positives (e.g. party indicated as PEP, but not correct)
    • Override DD: manualResult: NO PEP
    • Calculate RBA → rating = LOW
    • RBA system assessment is now APPROVED
    • Dossier can be moved to DONE
  • Case 2: DD is correct, but we do want to accept the dossier
    • Override RBA: manualAssessment: APPROVED. This overrides the systemAssessment: REJECTED
    • Dossier can be moved to APPROVED / DONE, because there was a manual approval of the risk
  • Case 3: DD is correct, we want to reject the dossier
    • No override of systemAssessment
    • Dossier can be moved to REJECTED / DONE

Rescreening

• Input for RBA calculation: all subjects, the relevant parameters and the results of those parameters + the unchangedSince timestamp.

Case 1

Scenario

• Dossier status: APPROVED
• No manualAssessment
• SystemAssessment: APPROVED
• No DD case management
• No changes from DD provider

• Rescreening
  • DD checks → nothing changed
    • unchangedSince remains the same on each DueDiligenceProviderResult
  • DD aggregation → nothing changed
    • unchangedSince remains the same on each DueDiligenceCheck
  • RBA calculation → nothing changed
    • The input for the RBA calculation didn’t change
    • The systemAssessment remains APPROVED

Case 2

Scenario

• Dossier status: APPROVED
• No manualAssessment
• SystemAssessment: APPROVED
• No DD case management
• Changes from DD provider

• Rescreening
  • DD checks → changes
    • unchangedSince updated on DueDiligenceProviderResult
  • DD aggregation → changes
    • unchangedSince updated on DueDiligenceCheck
  • RBA calculation → changes
    • The input for the RBA calculation changed
    • The systemAssessment remains APPROVED, because still low risk

Case 3

Scenario

• Dossier status: APPROVED
• No manualAssessment
• SystemAssessment: APPROVED
• No DD case management
• No changes from DD provider

• Rescreening
  • DD checks → nothing changed
    • unchangedSince remains the same on each DueDiligenceProviderResult
  • DD aggregation → nothing changed
    • unchangedSince remains the same on each DueDiligenceCheck
  • RBA calculation → nothing changed
    • The input for the RBA calculation didn’t change
    • The systemAssessment remains APPROVED

Additional technical impact

• Assessment feature must be configurable via module settings
• Additional data about the manualAssessment
  • Who
  • When
  • Why (comments: configurable required/not-required)
• Add assessment to dossier list overview
  • Allow to filter on assessment
• Generic actions/validation related to assessment
  • Block status transition to status X for role Y if assessment is Z
  • Do status transition to status X if assessment is Y
• Expose assessment in reporting
• Allow to do rescreening based on assessment → should be out of the box, because FinancialSpDossierFilter is used as input for the rescreening provider.
• Impact on existing configurations???
  • SwissLife: status diagram to be defined?
  • Crelan: what with the current dossier resolution & comments???
    • Out of scope
    • Idea:
      • Possible to not have a systemAssessment and only a manualAssessment, because the system is unable to calculate a systemAssessment.

Unrelated technical impact

• Make difference between events DOSSIER_UPDATED and DOSSIER_PUSHED:
  • As Is:
    • DOSSIER_UPDATED is thrown every time a dossier is pushed, independent if there were any changes
  • To Be:
    • DOSSIER_UPDATED is thrown when a dossiers is pushed and there were changes compared to the previous push
      • Can be used for SwissLife, because they push all dossiers independent if there were changes on their side, but they only want to trigger automation if there were changes pushed.
    • DOSSIER_PUSHED is thrown every time a dossier is pushed
      • Can be used for ALD, because functionally, they want to trigger automation every time they push a dossier, not taking into account if there were changes or not