Consent Management

As the Trust and Accounts team, ensure that we:

1. Obtain explicit user consent before sensitive account actions.

2. Comply with data privacy laws (e.g., GDPR).

3. Maintain an audit log of consent requests, approvals, and actions.

4. Provide seamless user experiences for consent across platforms: web, mobile, USSD, and back-office.

1. Achieve a 90% decrease in unconsented actions within 3 months post-implementation.

2. 100% of sensitive actions logged with all necessary audit details (e.g., requester, timestamps, action performed).

Current Situation

At present, sensitive actions can be carried out on a user's account without explicitly obtaining their consent. This poses several challenges:

1. Regulatory Compliance: It creates a risk of non-compliance with data protection laws such as the GDPR, which mandate that users must give informed and explicit consent before any action affecting their data or account is performed.

2. Transparency and Trust: Users may lose trust in the platform if they notice changes made to their account without their knowledge or approval.

3. Auditability: There is no comprehensive audit trail to verify who authorized the action, when it occurred, and what specific changes were made, leading to accountability gaps.

Case study: BRM Remapping

A clear example of this issue is the BRM remapping process:

1. Current Flow (Without Consent Management):

   • A Business Relationship Manager (BRM) raises a claim request to reassign a business to themselves.

   • The Business Owner (BOwner) simply sees that their BRM has changed without being notified or asked for permission.

2. Improved Flow (With Consent Management):

3. When the BRM raises a remapping request, the system triggers a consent request to the Business Owner.

4. The consent request includes clear details, such as the identity of the requesting BRM and the action they wish to perform.

5. The Business Owner must explicitly approve this request before any changes are implemented.

6. This process ensures that sensitive actions like BRM remapping are fully transparent, user-approved, and properly documented.

Benefits of Consent Management

1. User Control: Users are empowered to make decisions about their accounts.

2. Legal Compliance: Aligns with GDPR and other data protection regulations.

3. Audit Trail: Provides a clear, verifiable record of all consented actions, including details of who requested the action, when the request was made, and the outcome.

This approach not only addresses compliance and trust issues but also sets a strong foundation for user-centric account management practices.

cope

Internal Services

These are Moniepoint's internal services that may need to request user consent for sensitive actions. Examples include:

External Services

These are third-party services that may require access to Moniepoint users’ accounts for data or payment purposes. Examples include:

Constraints

1. Transparency:

2. Each consent request must inform the customer:

   • Who the requesting client is

   • The specific action the client wants to perform on their account.

3. Action Specificity:

4. Systems requesting consent must only be allowed to carry out the specific action tied to the consent request.

5. Single-Use Consent:

6. The first version (v1) of this feature will focus solely on one-time, single-use consent requests.

7. Communication Constraints:

   • SMS Notifications: Messages must be under 150 characters.

   • Push Notifications: Limited to 250 characters.

   • USSD Screens: Maximum display of 150 characters.

The key risks that the team has identified and is working to reduce.

v1 Consent management APIs - for internal services only

Types of consent

There are two types of consent:

1. Single-use consent: This is one-time consent for specific actions

2. Long-term consent: This consent type is for extended or recurring access to the user’s account. This consent type is revocable

API features

Request a consent

1. The client should pass a unique identifier for the user they’re requesting consent from

2. The API should respond with a unique token identifying the consent request

3. This token can only be used for the consented action

Notify the user of the consent request

A notification should be sent out on request for the customer to review.

1. For feature phone users: This message should be an SMS containing details of the consent request. The users should also be able to check the status of the request via USSD

2. For web/mobile app users: They should get a push notification with details about the client and the consent request being made

Approve a consent
There are 3 ways consent can be approved

1. For feature phone users: Approval should be done by dialling a USSD shortcode. To confirm the approval, the user will need to enter a PIN

2. For web/mobile app users: Approval will be done in-app and will require 2FA verification before approval

3. For in-person consent: 2FA verification will also be required for approval. This will be done when the in-person user walks into the Moniepoint Kiosk.

Reject a consent

1. All user types should be able to reject a consent in the same flow that they approve.

2. PIN/2FA isn’t required to reject a consent

3. Users should be required to pass a reason for rejection. For USSD users, there should be a default generic reason.

Revoke a consent

1. All users should be able to revoke long-term consent types.

Notify the system of the consent status

1. Once consent is requested, the client who requested the consent should get notified whether the consent has been approved or rejected

2. A consent request should also expire after ~5 mins

3. The status messages are:

   1. Rejected

   2. Expired

   3. Revoked [Terminal state]

   4. Approved

   5. Completed [Terminal state]

4. An action should not be carried out unless consent is “Approved”

Notify the user of the action status

1. Once the action has been carried out, the user must be notified of the status of the action.

Platforms for Consent Management

1. Web and Mobile:

2. Full functionality for requesting, approving, rejecting, and viewing consent history.

3. USSD:

   • View pending consent requests.

   • Approve or reject requests using USSD codes and PIN.

   • Receive SMS notifications with consent details.

4. Consent Link:

   • Allows users to grant consent via a link on any platform (e.g., Moniedesk).

   • Limited functionality: no notifications or history view.

Audit Log for Consent Management

Maintain a detailed audit log for every consent request, including:

1. Who made the request

2. When the request was made.

3. The status of the request.

4. The type of action carried out with the consent.

Future considerations

v2 Consent management APIs - for external services only

1. Consent Management SDK

2. Revocable Consent tokens: These are long-lived tokens that can be used for things like Direct Debit

Internal Systems

As an internal system, I want to:

1. Request consent from users for sensitive actions

   • Why: To ensure actions comply with user privacy and regulatory requirements.

   • Acceptance Criteria:

     • A consent request must include:

       • The unique identifier of the user (e.g., account ID).

       • A description of the action requiring consent (e.g., "BO remapping").

       • The expiry time for the consent request (default: 5 minutes).

     • A unique token must be generated for each consent request, tied to the specific action.

2. Create and use consent request templates

   • Why: To standardize the format and content of consent requests.

   • Acceptance Criteria:

     • Templates must include placeholders for key variables like user name, request type, and action details.

     • Templates must pass validation checks before being used to prevent incomplete requests.

3. Send a push notification or SMS to users for consent requests

   • Why: To notify users promptly and allow them to act on the request.

   • Acceptance Criteria:

     • The notification must include:

       • Client name (e.g., "Offline Sales Team").

       • Action details and why it’s needed.

       • USSD code (for SMS users) to act on the request.

4. Check the status of consent requests

   • Why: To monitor user responses and proceed accordingly.

   • Acceptance Criteria:

     • The consent status must be: Pending, Approved, Rejected, Expired, Revoked, or Completed.

     • An API endpoint must be available to fetch the current status of a consent request using the unique token.

5. Receive real-time updates on consent status

   • Why: To proceed with or halt the requested action based on the user’s decision.

   • Acceptance Criteria:

     • The system must receive a callback notification when consent is approved or rejected.

Moniepoint Users (Web & Mobile)

As a Moniepoint user, I want to:

1. Receive push notifications for consent requests

   • Why: So I am aware of actions requiring my approval.

   • Acceptance Criteria:

     • Notifications must include:

       • Who is requesting consent and why.

2. View pending consent requests

   • Why: To manage outstanding approvals or rejections.

   • Acceptance Criteria:

     • A dedicated section in the app must list all pending requests.

     • Each entry must show the action type, requestor, and expiry time.

3. Approve or reject consent requests

   • Why: To control the actions performed on my account.

   • Acceptance Criteria for Approval:

     • Approving must require 2FA (Facematch + OTP).

     • The app must show a confirmation message once approval is complete.

   • Acceptance Criteria for Rejection:

     • Users must select a reason from a predefined list.

     • Reasons include:

       • I did not request this action.

       • I don’t understand this.

       • I changed my mind.

4. View a history of all consent requests

   • Why: To track and audit previous approvals and rejections.

   • Acceptance Criteria:

     • A log of all past consent requests must include:

       • Request date and time.

       • Requesting party.

       • Status (Approved, Rejected, Expired, Revoked, Completed).

Moniepoint Users (USSD)

As a feature phone user, I want to:

1. Receive SMS notifications for consent requests

   • Why: So I can act on requests even without a smartphone.

   • Acceptance Criteria:

     • The SMS must include:

       • Requesting party and action details.

       • A unique USSD code to navigate directly to the request.

2. Approve or reject consent via USSD

   • Why: To control sensitive actions without relying on the app.

   • Acceptance Criteria:

     • USSD screens must display the consent details, action type, and expiry time.

     • Approvals require PIN input.

     • Rejections will have a default reason, such as "I did not request this action."

Consent Link (Universal)

As a Moniepoint user using a consent link, I want to:

1. View and act on consent requests from any platform

   • Why: To respond to requests regardless of the device I am using.

   • Acceptance Criteria:

     • The link must open a secure page where users can view consent details.

     • Users must be able to approve (with 2FA) or reject (with a reason).

     • A confirmation message must be displayed after an action is taken.

Back-Office Users

As a back-office user, I want to:

1. Trigger consent requests for sensitive actions

   • Why: To obtain user approval before making significant changes to their account.

   • Acceptance Criteria:

     • The system must require input for user details, action type, and justification for the request.

     • Requests must be logged for auditing purposes.

2. View an audit log of consent requests

   • Why: To ensure compliance and transparency.

   • Acceptance Criteria:

     • The log must include:

       • Requesting party.

       • Action details.

       • Status (Approved, Rejected, Expired, Revoked, Cancelled).

       • Timestamp for each status update.

We had two research sessions with the Offline sales team as well as the Moniedesk team:

Moniepoint end-user research
TBD

Offline sales

1. This is a critical aspect of the new remapping flow.

2. The solution developed works for their use case

3. They mentioned the user must provide clear rejection reasons.

Moniedesk team

1. The solution works for them, but it will be down to the product team to integrate it into their Moniedesk workflow

N/A

Mono’s widget: Mono’s connect widget allows users to give consent to access their financial data from the bank

Mixpanel

We need to set up the following event to track user interactions with the banner:

We would need to show users a pop-up banner to explain how Consent management works

1. Organize a demo for the CS team on how to ensure we’re requesting consent before carrying out sensitive actions

2. Create authority for certain back office staff to carry out consented actions and view the Consent management system audit.

1. We need to get the legal team aligned on the approach for getting consent from the user.

2. The system must comply with relevant data privacy laws.

3. Audit logs must be maintained for all consent requests and approvals for at least 7 years.

Security

1. Consent must be enforced for endpoints that consent is requested for

2. We must ensure that a client cannot act with a different consent ID

Privacy

1. The client must not be able to view/update sensitive information on the account without consent

2. Secure storage for tokens and consent records.

It's useful to answer anticipated questions from both internal stakeholders and external users ahead of the feature going live. In some situations, this might include updating your public FAQs or support documents.

TBD

TBD