> For the complete documentation index, see [llms.txt](https://docs.moderncollections.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.moderncollections.io/compliance-for-integrators/data-handling-pii.md).

# Data handling and PII

> **Not legal advice.** Get your own counsel.

## What PII we expose to integrators

Through the REST API and outbound webhooks, integrators see:

| Field                                         | PII level                                               |
| --------------------------------------------- | ------------------------------------------------------- |
| `debtor.company_name`                         | Low (business identifier)                               |
| `debtor.primary_domain`                       | Low                                                     |
| `debtor.primary_email`                        | Medium (especially if the contact is a sole proprietor) |
| `debtor.primary_phone`                        | Medium (high if it's a personal cell)                   |
| `debtor.city` / `debtor.state` / `debtor.zip` | Medium                                                  |
| Contact name and title in calls / emails      | Medium                                                  |
| Call transcript content                       | High — may include sensitive personal disclosure        |
| Email reply content                           | High                                                    |
| Stripe PaymentIntent IDs on payments          | Medium (financial identifier)                           |

The [`mc-api-mcp` MCP server](/mcp-servers/overview.md) exposes the same REST surface as tools, so everything in this table also applies to data your agents pull over MCP.

We do NOT expose:

* Debtor Social Security numbers (we don't collect them).
* Debtor credit-card numbers (stored only in Stripe; we have tokens).
* Debtor bank account / routing (also Stripe-tokenized).

## Your data handling obligations

### Encryption

* In transit: TLS 1.2+ (always; we won't accept webhooks over plain HTTP).
* At rest on your side: encrypt sensitive fields. Use cloud-provider KMS or equivalent.

### Access control

* Treat debtor PII as need-to-know.
* Audit access on your side. We audit access on ours.

### Retention

* Default platform retention: lifetime of the creditor account + 7 years (legally required for collections records in many states). The audit trail is append-only, enforced at the database level — updates and deletes are blocked by the database itself.
* Your retention should match or exceed (for audit purposes) — but no longer than your business legitimately needs.
* Honor right-to-deletion requests where applicable. The platform exposes a debtor-facing DSAR submission endpoint (`POST /v1/portal/dsar`) supporting these request kinds: `delete`, `access`, `opt_out_sale`, `opt_out_share`, `correct`. Responses are due within 45 days and are delivered encrypted.

### Cross-border transfer

* Be careful forwarding debtor data outside the US.
* We host in US regions. If you store in other regions, evaluate the legal implications.

## CCPA, CPRA, and state privacy laws

California Consumer Privacy Act and its successor CPRA apply if a debtor is a California consumer (which sometimes includes sole proprietors). Obligations include:

* Right to know what data you hold
* Right to delete (with exceptions for collections records)
* Right to opt-out of sale (collections data isn't "sold" in the CCPA sense, but be careful with vendor sharing)

Similar laws now in: Colorado, Virginia, Connecticut, Utah, Texas, Oregon, Iowa, Montana, Tennessee, Delaware, New Jersey, New Hampshire, Indiana, and several more rolling out 2025-2027.

## SOC 2

We are SOC 2 Type II. Your security review should cover:

* Our auditor's letter (request via partners@)
* Our security policies (likewise)
* Sub-processor list (available on request)

## Vendor sharing

If you forward our webhook payloads to your own sub-processors (Slack, Datadog, Snowflake, etc.), make sure those sub-processors are:

* Listed in your privacy policy
* Bound by DPAs where required
* Configured with appropriate access controls

## Common mistakes

| Mistake                                                                  | Consequence                                         |
| ------------------------------------------------------------------------ | --------------------------------------------------- |
| Logging webhook payloads to a SaaS log aggregator with broad team access | Disclosure risk                                     |
| Forwarding transcripts to a CRM that's open to sales team                | Third-party disclosure risk under FDCPA-style rules |
| Storing recording audio on an unrestricted S3 bucket                     | Public exposure risk                                |
| Caching debtor PII in browser localStorage on a creditor-side dashboard  | XSS / theft risk                                    |
| Using debtor PII in test fixtures committed to a public repo             | Permanent exposure; basically can't be cleaned up   |

## Incident response

If you have a security incident affecting debtor PII received from us:

1. Contain immediately.
2. Notify us within 24 hours: <security@moderncollections.io>.
3. Cooperate on coordinated breach notification to affected debtors and regulators.

## See also

* [FDCPA for integrators](/compliance-for-integrators/fdcpa-for-integrators.md)
* [TCPA for integrators](/compliance-for-integrators/tcpa-for-integrators.md)
* [Recording consent](/compliance-for-integrators/recording-consent.md)
* [Authentication: security expectations](/getting-started/authentication.md#security-expectations-on-the-integrator-side)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.moderncollections.io/compliance-for-integrators/data-handling-pii.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
