SaFi Bank Space : Customer KYC survey

The KYC survey (see FE: survey page (for onboarding)) is designed:

• to have a variable number of questions,

• to have a variable number of options for each question,

• to have the possibility of skipping questions or the whole survey based on the selected option.

Design (model):

• Survey

  • has own identifier (UUID),

  • contains a list of questions [question identifiers].

• Survey Question

  • has own unique identifier per the survey (e.g. OCCUPATION),

  • has a step - the current progress identifier in the survey (the progress bar between elements 1 and 2 https://safibank.atlassian.net/wiki/spaces/ITArch/pages/203751425/FE+survey+page+for+onboarding#Elements),

  • has a question wording (element 2 label https://safibank.atlassian.net/wiki/spaces/ITArch/pages/203751425/FE+survey+page+for+onboarding#Elements),

  • has a question description wording (element 3 label https://safibank.atlassian.net/wiki/spaces/ITArch/pages/203751425/FE+survey+page+for+onboarding#Elements),

  • has a list of options,

  • has (default) next question identifier or END value - what question should be following after the current one (END means the end of the survey) (e.g. SOURCE_OF_INCOME).

• Survey Option

  • has own unique identifier per the question (e.g. STUDENT),

  • has an option wording (element 4 label https://safibank.atlassian.net/wiki/spaces/ITArch/pages/203751425/FE+survey+page+for+onboarding#Elements),

  • has OPTIONAL next question identifier or END value - if the value is present it will override the behavior of the question’s default next question identifier.

• Survey Wording

  • contains an identifier with 4 different wordings (English-formal, English-friendly, Taglish-formal, Taglish-friendly).

• Survey Submission [filled in a survey by the customer]

  • identifies the Survey (surveyId),

  • identifies the Customer (customerId),

  • contains a list of the answers [Question identifier + Option identifier pairs] (e.g. OCCUPATION → STUDENT, SOURCE_OF_INCOME → SALARY),

  • each submission is validated against the identified survey.

• Survey Catalogue

  • it’s a range of possible answers (Question identifier + Option identifier pairs) with associated metadata (plain JSON),

  • each survey creation is validated against the catalogue,

  • the metadata could be used for storing e.g. risk values per selected option.

Design remarks:

• a survey instance should be immutable,

• each major survey update (adding/deleting an option, adding/deleting a question, etc.) means a new survey creation,

  • since each survey creation is validated against the catalogue → the missing answers have to be inserted into the catalogue as the first step and then a new survey can be created,

• it’s possible to update the wording of the question/option in the database BUT DO IT WISELY (it is a suggested way how to fix a typo) - it affects existing customer’s choices,

• backward/forward compatibility of surveys is reached by using question/option (“natural”) identifiers (the same questions/answers in different surveys can have the same identifiers),

• default survey will be stored in the database when no survey is present there (see: SurveyInitServiceImpl).