Fraud Analytics Pilot Using Pseudonymized Benefits Data
An agency benefits office wants to run a six-month fraud analytics pilot. It will combine eligibility records for 2.3 million households with geolocation data from the agency mobile app and a commercial data broker property records. The pilot team says the dataset is de-identified because names and full SSNs are replaced with salted hashes; it retains date of birth, five-digit ZIP code, household size, and benefit amount. The vendor will store the data in a commercial cloud and use it to train a model, then return the model to the agency. The existing PIA covers the benefits system but not the mobile app, the broker data, or model training. The program office wants to launch in 45 days and asks whether a new PIA is needed and whether the data can be treated as non-PII. The privacy officer is also concerned about the broker data rights and retention.
1. Is a new or updated PIA required, and can the data be treated as non-PII?
Read the worked answer
A new or updated PIA is required. The pilot adds a new purpose, a new data source, a new mobile data flow, a new vendor, and model training. The existing PIA did not cover those. The data should not be treated as non-PII. Replacing names and full SSNs with salted hashes is pseudonymization; retaining DOB, five-digit ZIP, household size, and benefit amount creates a realistic re-identification risk, especially when combined with broker property records. Treat the data as PII with heightened privacy risk and document the re-identification analysis. Apply data minimization: question whether each field is necessary, use the lowest precision needed, and set retention. The 45-day launch schedule is not a reason to skip the PIA. If the PIA cannot be completed, narrow the pilot or delay it.
2. What authority, notice, and records-management issues must be resolved before launch?
Read the worked answer
Establish authority to collect and use the data under the applicable privacy law and agency policy. Update the privacy notice so individuals understand the fraud-analytics use, the broker data, and the model training. Determine whether the pilot creates a new system of records or a new routine use; if so, publish or amend the SORN before operation. Review computer-matching requirements if the agency is matching records with another organization. The broker data needs a data-use agreement that limits secondary use, resale, and retention. Model training creates a derived artifact; decide whether the model is agency data and how it will be retained and shared. Document all of this in the PIA and the SSP.
3. What privacy and vendor controls should the agency assess and monitor during the pilot?
Read the worked answer
Select and assess privacy controls: authority to collect, purpose specification, consent where required, privacy notice, SORN, specific PII categories, and matching requirements. For the vendor, use SA-9-type controls: flow-down privacy requirements, access limits, encryption, logging, incident notification, and return or destruction of data. Monitor the pilot with privacy metrics: access reviews, re-identification testing, retention compliance, and model-use review. Do not let the vendor use the data for its own purposes. At the end of six months, decide whether to continue, extend, or terminate, and update the PIA, SORN, and retention schedule. If the pilot expands, treat it as a significant change.