- Created by Ahmed-Tijani Umar , last modified on Dec 04, 2024
You are viewing an old version of this content. View the current version.
Compare with Current View Version History
« Previous Version 3 Next »
Owner | |
---|---|
TPM | Ryan |
EA | Isaac |
Summary | Get consent before sensitive actions are carried out on Moniepoint user's account. |
Status | DISCOVERY | |
Proposed delivery | 12th of December 2024 |
Next Milestone | 10th November 2024 |
Problem Definition
As the Trust and Accounts team, ensure that we:
Obtain explicit user consent before sensitive account actions.
Comply with data privacy laws (e.g., GDPR).
Maintain an audit log of consent requests, approvals, and actions.
Provide seamless user experiences for consent across platforms: web, mobile, USSD, and back-office.
Achieve a 90% decrease in unconsented actions within 3 months post-implementation.
100% of sensitive actions logged with all necessary audit details (e.g., requester, timestamps, action performed).
Responsible | Trust and Accounts |
Accountable | Umar Ryan |
Consulted | Adegoke Ope |
Informed | Ope, Operations, Channels |
Read more about BO remapping /wiki/spaces/MAE/pages/1467940877
Current Situation
At present, sensitive actions can be carried out on a user's account without explicitly obtaining their consent. This poses several challenges:
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.
Transparency and Trust: Users may lose trust in the platform if they notice changes made to their account without their knowledge or approval.
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:
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.
Improved Flow (With Consent Management):
When the BRM raises a remapping request, the system triggers a consent request to the Business Owner.
The consent request includes clear details, such as the identity of the requesting BRM and the action they wish to perform.
The Business Owner must explicitly approve this request before any changes are implemented.
This process ensures that sensitive actions like BRM remapping are fully transparent, user-approved, and properly documented.
Benefits of Consent Management
User Control: Users are empowered to make decisions about their accounts.
Legal Compliance: Aligns with GDPR and other data protection regulations.
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.
cope
Internal Services
These are Moniepoint's internal services that may need to request user consent for sensitive actions. Examples include:
Team | Consented Feature |
---|---|
Offline Sales | BO Remapping |
Trust and Account | Profile Management |
External Services
These are third-party services that may require access to Moniepoint users’ accounts for data or payment purposes. Examples include:
Team | Consented Feature |
---|---|
NIBSS | Direct Debit |
Third-party Lenders | Data Access (e.g., Renmoney, Carbon) |
Account Statement Services | Account Statement Requests |
Constraints
Transparency:
Each consent request must inform the customer:
Who the requesting client is
The specific action the client wants to perform on their account.
Action Specificity:
Systems requesting consent must only be allowed to carry out the specific action tied to the consent request.
Single-Use Consent:
The first version (v1) of this feature will focus solely on one-time, single-use consent requests.
Communication Constraints:
SMS Notifications: Messages must be under 150 characters.
Push Notifications: Limited to 250 characters.
USSD Screens: Maximum display of 150 characters.
Reviewed by | Status |
---|---|
|
|
The key risks that the team has identified and is working to reduce.
Risk | Mitigation |
---|---|
Users should clearly know what they’re consenting to | We should use a template to control the messaging the system sets. |
System should only be able to carry out action directly tied to their consent | An audit log should be kept for who requested, the status of the consent andr what API was called |
Consent management API fails | Making the APIs fault tolerant |
Consent management API becomes a point of failure in the consent action chain | Ensure that the integrating team carries out the consented action, we are only concerned with getting consent from the user. |
High volume of requests impacting performance | Implement load balancing and caching mechanisms |
Security vulnerabilities | Conduct regular security audits and use secure tokens |
Customer confusion over consent notifications | Provide clear, educational messaging in notifications |
Solution Definition
v1 Consent management APIs - for internal services only
Types of consent
There are two types of consent:
Single-use consent: This is one-time consent for specific actions
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
The client should pass a unique identifier for the user they’re requesting consent from
The API should respond with a unique token identifying the consent request
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.
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
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
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
For web/mobile app users: Approval will be done in-app and will require 2FA verification before approval
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
All user types should be able to reject a consent in the same flow that they approve.
PIN/2FA isn’t required to reject a consent
Users should be required to pass a reason for rejection. For USSD users, there should be a default generic reason.
Revoke a consent
All users should be able to revoke long-term consent types.
Notify the system of the consent status
Once consent is requested, the client who requested the consent should get notified whether the consent has been approved or rejected
A consent request should also expire after ~5 mins
The status messages are:
Rejected
Expired
Revoked [Terminal state]
Approved
Completed [Terminal state]
An action should not be carried out unless consent is “Approved”
Notify the user of the action status
Once the action has been carried out, the user must be notified of the status of the action.
Platforms for Consent Management
Web and Mobile:
Full functionality for requesting, approving, rejecting, and viewing consent history.
USSD:
View pending consent requests.
Approve or reject requests using USSD codes and PIN.
Receive SMS notifications with consent details.
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:
Who made the request
When the request was made.
The status of the request.
The type of action carried out with the consent.
Future considerations
v2 Consent management APIs - for external services only
Consent Management SDK
Revocable Consent tokens: These are long-lived tokens that can be used for things like Direct Debit
Reviewed by | Status |
---|---|
|
|
Internal Systems
As an internal system, I want to:
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.
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.
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.
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.
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:
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.
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.
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.
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:
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.
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:
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:
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.
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
See BO remapping flow on Figma here
This is a critical aspect of the new remapping flow.
The solution developed works for their use case
They mentioned the user must provide clear rejection reasons.
Moniedesk team
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
![]() | ![]()
| ![]()
|
Question | Decision made | Decider | Date |
Who makes the consented action | The team who requested consent from the user |
| N/A |
How do we know when the action has been carried out? | The system should call the consent management API to notify that the action has been carried out |
| N/A |
Launch Readiness
TARGET DATE | MILESTONE | DESCRIPTION | EXIT CRITERIA |
6th Dec 2024 | 🛑 Pilot | We’re done with development and QA has tested | No P0 or P1 bugs on a rolling 7-day basis |
12 Dec 2024 | 🛑 Beta | We’re in Beta | Test with at least 10 customers on Beta |
TBD | 🛑 Early Access | N/A | At least 1 win from every major competitor |
TBD | 🛑 Launch | N/A | Measure and monitor |
Mixpanel
We need to set up the following event to track user interactions with the banner:
Event name | Description | Attribute(s) |
---|---|---|
consent_requested | This event is fired when the client requests consent from user | Product: What product are they requesting consent for Type: is it revocable or not Where: personal app, business app, web, consent link? |
consent_approved | This event is fired when the Moniepoint user approves the consent request | Product: What product are they requesting consent for Type: is it revocable or not Where: personal app, business app, web, consent link? |
consent_rejected | This event is fired when the Moniepoint user rejects the consent request | Product: What product are they requesting consent for Type: is it revocable or not Where: personal app, business app, web, consent link? |
We would need to show users a pop-up banner to explain how Consent management works
Organize a demo for the CS team on how to ensure we’re requesting consent before carrying out sensitive actions
Create authority for certain back office staff to carry out consented actions and view the Consent management system audit.
We need to get the legal team aligned on the approach for getting consent from the user.
The system must comply with relevant data privacy laws.
Audit logs must be maintained for all consent requests and approvals for at least 7 years.
Security
Consent must be enforced for endpoints that consent is requested for
We must ensure that a client cannot act with a different consent ID
Privacy
The client must not be able to view/update sensitive information on the account without consent
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.
Impact
TBD
Category | Metric | Goal |
---|---|---|
User Engagement | Approval/ Rejection rate | High Consent Approval rate (this indicates high trust) |
Conversions | % of users who complete the consent request flow (e.g., completing KYC or activating MFA). | 90% |
| Time to process consent requests. | less than a minute |
| % of successful notifications delivered. | 99% |
| % of consent approvals within the first 3 notifications sent. | 88% |
| % success rate for consent requests | 85% |
Performance | Banner load success rate | 99%+ |
Category | Metric | Goal |
---|---|---|
Satisfaction | Customer feedback survey | Positive perception (4/5+ rating) |
TBD
Changelog
DATE | DESCRIPTION |
- No labels
Add Comment