SaFi Bank Space : Consent mng. system

Status

in progres

Impact

MEDIUM

Driver

Zbyněk Melichar (Unlicensed)

Approver

Lukas Civin

Contributors

Juraj Macháč (Unlicensed) Ján Borovský (Unlicensed) Lukas Civin

Informed

Due date

Resources

Background

HL requirements

  • The consent management system (CMS) sits next to the Customer information File in the backend architecture of systems to easily connect "Consent" with "Data Subject (client)". It does not hold any PII data.

  • CMS is real-time connected to consent collection points - such as screen during the onboarding process where the client gives consent. It records Internal identification of the Customer (no PII here); identification of session; timestamp, version, and type of consent; also "flag" if the consent can be easily revoked by the customer in the app

  • CMS also serves as a single repository of consents. The collection points request a recent version of the proper type of consent to be used. The push of consent can be done manually, but the version of the consent (eg. wording) cannot be changed in the front-end without changing the version in CMS. The sequence of new consent versions is

1. create a new version of consent;

2. insert to CMS

3. Push/Pull the consent to the right collection point (such as web cookie or onboarding consent)

  • CMS has a front-end (or uses Customer File frontend) to review consents associated with customers. The ability to revoke consent requires higher access right for the back-end operators. Search/Filter functionality required.

  • Mobile App is having a screen to review customers' consent. (Such as Marketing communication consent, Data use, cookies) The customer has the ability to see (link) the wording of the given consent. And some consent can be revoked by customers in the app.

  • The same screen in the Mobile app may serve as a collection point of new consents if needed

  • Level 2 requirement - The app has the ability to show the history of consent. When a new T&Cs are provided, both versions are visible

How you should store consent

Collecting consent for data processing is one thing. Proper documentation of the collected data is another. In order to demonstrate that you’ve obtained lawful consent from your users, you should maintain the following records:

  • Who gave consent - the name of the individual or another identifier (such as email address, cookie, or device ID)

  • When they gave consent - an online record that includes a timestamp

  • What they consented to - a list of the specific purposes for using personal data that they agreed to

  • Whether and when they have withdrawn or changed their consent

Type of consents to be gathered:

  • Marketing (send marketing information, there should be also a preferred channel (Mobile app, SMS, Email, Whatsapp?, Viber?, ) )

    • Opt-in (Double opt-in)/ Opt-out

    • Time

    • Preferred channels

    • History

    • More type of marketing consent?

    • Source (mobile app, B.O.F.E)

    • Validation of the consent?

  • Bank contract

    • Time

    • Version

    • History

    • More type of bank contract?

    • Source (Mobile app)

  • web cookies (do we need them right now)

Where should be visible

  • Mobile app

    • get the consent from the customer

    • display the consent to the customer

    • type of consents

      • Bank contract (cannot be changed)

      • Marketing consent (can be changed by customer anytime)

  • Meiro

    • Marketing consent (main trigger to select customer to campaign)

  • B.O.F.E

    • Customers can opt-in/opt-out during the call (just marketing data)