Xoom data deletion for GDPR/CCPA

Context

GDPR landed in 2018 with a deadline most large payments platforms were going to miss on a technicality. The right-to-erasure piece was the hardest one for any company that had been retaining customer data across dozens of internal systems for a decade. CCPA arrived months later with its own variant. For Xoom — at the time the international money-transfer arm of PayPal — these weren't just compliance checkboxes. They were the gating prerequisite to a full European launch. No automated deletion, no Europe.

The reality on the ground was uglier than the regulation reads. A Xoom customer's data lived in dozens of services: KYC, transactions, fraud, customer support, marketing, partner reconciliation. "Delete this customer" was not a single SQL statement. It was a coordinated dance across a long list of downstream teams, each with its own retention rules — some of them required by financial law to keep certain records on file for years even after a deletion request.

Role

Product Manager. I led the cross-org program — orchestration design, the internal API contract, the notification system every downstream team had to consume, the anonymization paths, and the operational controls. The hard part of this work was not technical. It was getting every team at Xoom that touched PII to implement against the same contract on the same timeline.

What we shipped

An end-to-end automated data-deletion system covering both deletion and lawful retention:

1. Internal deletion API. A single, auditable surface that customer support and internal systems called when a customer exercised right-to-erasure under GDPR or right-to-delete under CCPA. The API was the source of truth for what was requested, when, and how it resolved.
2. Notification queue for downstream systems. Every system that held PII subscribed to a deletion-events queue. When a request arrived, every downstream service received a message it had to either acknowledge (data deleted) or reject (data retained under a legal hold, with the specific statute named).
3. Retention policy orchestration. For records that financial regulators required us to keep — anti-money-laundering trails, transaction records, KYC artifacts — the system marked them as retained-with-justification rather than deleted. The justification was logged and auditable.
4. Anonymization where deletion wasn't an option. Where the underlying business need was satisfied without identifiable data — analytics, fraud models, aggregates — we built anonymization paths so the data stayed useful without the customer remaining identifiable.
5. Customer support case logging. Every request, every team's response, every retained-with-justification record was tied to a customer support case, so the audit trail for any specific customer could be reconstructed from a single record.
6. Controls and per-team adoption dashboards. End-to-end SLA tracking on deletion completeness, per-system adoption metrics, and the controls compliance and audit needed to sign off on the work.

Product decisions worth writing down

Treat retention as a first-class peer of deletion. GDPR-readiness systems that only know how to delete fail at the first encounter with banking regulators. Designing the system so "retain with named legal basis" was a valid response — and a logged one — was what made the program acceptable to compliance, legal, and ops at the same time.

The hard part is not the orchestration; it's the adoption. The deletion API was technically straightforward. The work that took the most time was getting every team that touched PII to implement against the contract on the schedule. The product job was less about engineering design and more about removing per-team friction — clear contracts, low-cost integration, visible per-team dashboards, and escalation where it was warranted.

Anonymization is a third option, and a good one. "Delete it" and "keep it" are not the only choices when a customer exercises their rights. For datasets where the value is statistical — fraud-signal aggregates, behavioral analytics — anonymization preserves the value to the business without preserving the identity of the customer. Building the third path in from day one prevented the worse outcome of "we deleted the customer but lost the fraud signal."

Adoption dashboards are part of the product, too. Reaching 100% deletion adoption across every downstream system at Xoom required visibility — every team's adoption rate, every team's SLA breach count, every team's open exceptions. The dashboards weren't an internal tool. They were the mechanism that drove the program to completion.

Outcome

100% GDPR and CCPA compliance across every Xoom system that held customer data, achieved on the timeline that unlocked the full European launch. The internal deletion API became the standard contract for customer-data lifecycle events across Xoom and provided the foundation for downstream privacy work as the regulatory landscape kept evolving.