# Running a data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.View full definition → audit that regulators respect
An examiner from the OCC (Office of the Comptroller of the Currency, which supervises US national banks) walks into a fintech's bank-partnership review and asks one question first: "Show me who accessed customer Social Security numbers last Tuesday, and why." If the answer takes more than a few minutes to produce, the audit has already gone badly.
This is the reality of fintech data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.View full definition → in 2026. Regulators don't want a policy binder. They want proof that controls actually run, every day, on real data. This lesson builds the audit script itself: the exact sequence a well-run compliance or data team walks through before a regulator ever shows up.
Fintechs sit at the intersection of banking law and tech-platform speed, which means they inherit obligations from multiple regimes at once:
Examiners increasingly test the same three things across all these regimes: who can touch the data, what the data actually is, and where it goes after it leaves the building. That maps directly to the three-part audit below.
The goal: prove that access to sensitive data is restricted, logged, and reviewed, not just theoretically restricted by a policy document.
Step 1: Pull the access matrix. List every system holding customer data (core banking ledger, KYC vendor, fraud model, customer support CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.View full definition →) against every role that can read or write to it. If you can't produce this in under a day, that's itself a finding.
Step 2: Test least privilege. For a sample of 20-30 employees, check whether their actual access matches their job function. A common finding: a former underwriting analyst who moved to marketing still has read access to loan files six months later.
Step 3: Check authentication strength. Are privileged accounts (admins, database engineers) protected by MFA (multi-factor authentication)? Examiners under the FFIEC (Federal Financial Institutions Examination Council) guidance treat single-factor admin access as a red flag by default.
Step 4: Review the access log itself. Not just "does a log exist" but "does anyone read it." Ask: who reviewed the privileged-access log last month, and what did they flag?
A simple query a data or security team should be able to run on demand:
SELECT user_id, resource_accessed, access_timestamp, action_type
FROM access_logs
WHERE resource_sensitivity = 'PII_HIGH'
AND access_timestamp >= NOW() - INTERVAL '30 days'
ORDER BY user_id;If this query doesn't exist, or takes engineering days to build, you have no real access audit trail. That gap is exactly what an OCC or FCA examiner is trained to probe.
Regulators want to see that not all data is treated equally, because it isn't legally equal.
Tiering example most fintechs use:
| Tier | Example data | Handling requirement |
|---|---|---|
| Restricted | SSN, account number, biometric ID | Encrypted at rest and in transit, access logged, MFA required |
| Confidential | Income, transaction history, credit score | Role-based access, masked in non-production environments |
| Internal | Aggregated usage stats | Standard employee access |
| Public | Marketing content | No restriction |
The audit test: pick five random database tables and ask the data team to name the classification tier and justify it. A frequent failure: a "test" or "staging" database that's a full copy of production, unmasked, accessible to twenty engineers. This single finding shows up repeatedly in enforcement actions, including in the FTC's Section 5 actions against fintechs for unfair data practices (FTC enforcement actions database).
Data minimization check: does the fintech still hold data it no longer needs? GDPR's storage limitation principle and many US state privacy laws (e.g., California's CCPA/CPRA) require deletion once the purpose ends. Ask: what's the deletion policy for a closed account, and can you show it executing, not just written down?
This is where fintechs get caught most often, because the business model depends on sharing data with partners: bank sponsors, KYC/AML vendors (know-your-customer, anti-money-laundering), payment processors, credit bureaus, ad platforms.
Step 1: Inventory every third party receiving customer data. Not just "we use Plaid for bank-account verification" but the specific data fields transmitted.
Step 2: Match each transfer to a legal basis. GLBA requires a privacy notice covering sharing categories; GDPR requires a lawful basis (consent, contract, legitimate interest) per transfer; CFPB's 1033 rule requires the consumer's affirmative authorization for data shared via open banking APIs.
Step 3: Check the vendor contract for a Data Processing Agreement (DPA), the legal document specifying how a vendor must handle, secure, and delete shared data. Examiners routinely ask for the DPA, not just the commercial contract.
Step 4: Trace one real transaction end to end. Pick a single customer's loan application and ask: which third parties touched this record, in what order, and where's the log entry for each handoff? This "follow one file" method is a known FCA examination technique because it exposes gaps that aggregate reports hide.
Knowledge check
1. An examiner asks a fintech to show who accessed customer SSNs on a specific day and why. What does this question primarily test?
2. Why do fintechs face a more complex data governance burden than a typical single-jurisdiction bank?
3. According to the lesson, what common underlying question do examiners across GLBA, GDPR, FCA, and CFPB 1033 regimes tend to test for?
4. Select ALL correct answers about why a written data governance policy binder is insufficient for regulators in 2026.
Select all the correct answers.
5. Select ALL correct answers about the regulatory regimes described as applying to fintechs.
Select all the correct answers.
Put the three parts together into a repeatable quarterly cycle:
1. Access snapshot: pull and review the privileged-access log.
2. Classification spot-check: sample five data stores, verify tier and masking.
3. Third-party trace: follow one customer record through every vendor it touches.
4. Remediation log: document every finding and the fix, with a date. Examiners weight "did you find and fix it yourselves" far more favorably than a clean report with zero findings, since zero findings from a real audit is statistically implausible.
For a useful public template of what examiners look for structurally, the OCC publishes its own handbook sections on third-party risk management, worth skimming for the actual checklist language: OCC Comptroller's Handbook: Third-Party Relationships.
🎬 [VIDEO: "How Bank Examiners Actually Review Your Data Controls" - youtube.com - search for FFIEC or OCC examiner-training walkthroughs on IT and data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.View full definition → exams, useful for seeing the examiner's checklist mindset firsthand]