Financial data-sharing consent and security checklist

• The product purpose is stated in one sentence.
• A named owner is accountable for the connection.
• Each data category is necessary for that purpose.
• Optional uses are separated from core service delivery.
• Read access is separated from payment or write authority.
• The review identifies the data provider, app, aggregator, and processors.
• Marketing labels do not replace legal entity names.

• The screen names the service requesting access.
• Any aggregator is disclosed in understandable language.
• Connected institutions and accounts are visible.
• Data categories are specific.
• One-time and continuing access are distinguished.
• Duration or expiration is shown.
• Payment-initiation permission has its own treatment.
• Revocation instructions are available before approval.
• Retention and deletion terms are accessible.
• The consent version and timestamp are retained.

Consumer Consent Screen Must Show

• Service requesting access
• Aggregator disclosed in plain language
• Connected institutions and accounts
• Specific data categories
• One-time vs continuing access
• Duration or expiration
• Revocation instructions before approval

• Every external and internal API endpoint has an owner.
• Clients and redirect locations are registered.
• Supported versions and retirement dates are known.
• Data fields and units have a maintained schema.
• Pending, posted, reversed, and deleted states are defined.
• Errors distinguish authorization, rate, format, and provider failures.
• Test and production credentials are separated.
• Undocumented endpoints are blocked or removed.
• If using an industry API standard, the Financial Data Exchange (FDX) API specification version and any deviations are documented; FDX is an industry standard, not a law.

• The consumer authenticates through the intended institution or identity service.
• The app does not collect a bank password unless the method explicitly requires it and the risk is approved.
• Multifactor steps cannot be bypassed by a lower-assurance recovery path.
• Access tokens are scoped to approved accounts and actions.
• Token lifetime matches the authorization.
• Refresh tokens are protected and rotated under policy.
• Client authentication is appropriate to the deployment.
• Revoked tokens fail promptly.
• Privileged support access is separately authorized and logged.

• The service requests only required accounts.
• The date range is no broader than needed.
• Full account and routing details are excluded where masked values work.
• Raw source fields are preserved or traceable.
• Derived fields identify the transformation and version.
• Available and ledger balances are not merged silently.
• Pending items are not treated as final postings.
• Time zone, currency, sign, and decimal rules are explicit.
• Test data cannot reach production analytics.

• Data is encrypted in transit using approved configurations.
• Sensitive stored data is protected under a documented key model.
• Passwords, tokens, and API secrets do not appear in logs.
• Secrets are held in an approved secret-management system.
• Backups follow retention and access rules.
• Support exports are access-controlled and expire.
• Lower environments use synthetic or appropriately protected data.
• Data location and cross-border handling are documented.

• Rate controls exist per client, user, and sensitive action where appropriate.
• Input and output validation follows the schema.
• Unusual token use and retrieval volume generate alerts.
• Repeated failures do not expose account existence or secrets.
• Authorization decisions are made server-side.
• Payment instructions receive transaction-level validation.
• Emergency blocking can target one client without disabling every connection.
• Availability controls do not replay a completed payment.

• Each access has a timestamp, client, account reference, scope, and outcome.
• The log distinguishes a bank fetch from an app cache read.
• Transformation versions are traceable.
• Consumer revocations create an auditable event.
• Deletion jobs produce completion and exception records.
• Log retention supports disputes without keeping secrets.
• Clock sources and time zones are consistent.
• Investigators can trace a displayed value back to its source field.

• The aggregator's legal entity and service are documented. Examples teams may encounter include Plaid, Yodlee, MX, Finicity, and Akoya; verify the contracting entity and exact service.
• Subprocessors are inventoried.
• Contracts address permitted uses, security, incidents, retention, and exit.
• Onward sharing is consistent with the consumer-facing disclosure.
• The provider can disable or migrate a connection safely.
• Vendor outages and schema changes have response owners.
• Audit evidence is current and relevant to the exact service.

• Applicable privacy regimes and exemptions were identified.
• Notices match current collection and disclosure practices.
• Any opt-out mechanism reaches the systems that perform sharing.
• New uses receive review before deployment.
• Data sale, advertising, profiling, and model-training uses are separately assessed.
• Reuse and redisclosure restrictions flow to recipients where applicable.
• For U.S. coverage, counsel assesses Dodd-Frank Act Section 1033 and the CFPB's Personal Financial Data Rights Rule, including their current legal status and applicability.
• GLBA and the applicable implementing privacy rule are identified, including the FTC's 16 CFR Part 313 or CFPB Regulation P (12 CFR Part 1016), as relevant.
• FCRA permissible-purpose requirements are assessed before obtaining or using a consumer report, and consumer reporting agency or furnisher obligations are considered when applicable.
• Applicable state privacy statutes are assessed, including California's CCPA, as amended by the CPRA; relevant definitions, exemptions, sale or sharing rules, and opt-out duties are mapped to the data flow.
• Consumers have an appropriate escalation route, such as the CFPB complaint portal or FTC ReportFraud.

• The app provides a clear disconnection control.
• The institution can revoke the authorization or token.
• Revocation blocks later retrieval and payment initiation.
• Cached data is labeled with its last-fetch time.
• Deletion is a separate documented workflow.
• Retention exceptions name the data, reason, and period.
• Backups and processors are included in the disposition plan.
• Closing the product account triggers connection review.

• Consumers can report a wrong imported value.
• Support can identify the source provider and aggregator.
• The procedure separates source error, transport error, mapping error, and stale cache.
• Corrections propagate to every affected display and decision.
• The original record and correction are preserved appropriately.
• Unauthorized transactions follow the applicable incident and dispute process.

• Contacts exist for the institution, app, aggregator, and processors.
• The plan can revoke clients, tokens, accounts, or scopes selectively.
• Credential exposure and data exposure have distinct actions.
• Notification decisions have assigned legal and operational owners.
• Evidence preservation starts before routine logs roll over.
• Recovery includes validating data integrity, not only service uptime.
• Consumers receive direct steps tied to the incident.