Why CallCompute Stores ANIs and How We Keep Them Safe

CallCompute is buyer-side software. We don't sell, route or broker calls. We take the security of the data we handle seriously. As part of our real-time bidding (RTB) engine, we ingest and store consumer Automatic Number Identification (ANI), the caller's phone number, to support intelligent call buying and bidding decisions. We handle that data under defined privacy and security controls, and we limit access to and exposure of the ANI throughout the workflow.

Why We Store ANIs

Storing ANIs is essential to delivering high-quality, performance-optimized results for our clients. We use them to:

1. Detect and Prevent Duplicate Opportunities
   We identify duplicate call opportunities across the call suppliers you buy from, so you don't pay twice for the same call.

2. Enable Future Data Enrichment
   Storing ANIs will allow buying decisions to take context or prior engagement into account, improving bidding accuracy over time.

3. Support Algorithmic Decision-Making
   Our proprietary algorithms leverage enriched call-level attributes to inform bidding, within the controls described below.

How We Handle ANI Exposure

While we may ingest the full ANI from the call supplier, we do not share that ANI with the advertiser (our client) unless they purchase the call. In the event of a purchase:

• The call connects to the client's phone system.
• The client naturally receives the caller's phone number via standard caller ID.

This is the only point at which the advertiser gains access to the full ANI, because they are now directly interacting with the consumer.

Reporting by RTBID, Not Phone Number

For all bidding and reporting activity that occurs before a call is purchased:

• We track and log activity using a unique internal identifier called the RTB ID.
• This RTB ID is included in client-facing reports and is the only identifier used when advertisers report conversion outcomes.
• Full ANIs are not shown in client-facing reports unless the call was purchased.

This structure lets you track performance and report outcomes without seeing consumer phone numbers for calls you didn't buy.

Exception: Using Advertiser-Provided Lookup Services

In rare cases, a client may provide a tool, such as an internal Do Not Call list API or an existing customer lookup service, that requires use of the full ANI before deciding whether to purchase a call. In those scenarios:

• The full ANI is passed only to the client's service, for that limited, contractual purpose.
• It is not exposed to the client directly, nor is it used outside the scope of that lookup.

These exceptions are documented and only used when agreed upon in advance.

How We Protect ANI Data

CallCompute's controls include:

• Encryption of ANIs at rest and in transit.
• Access controls with role-based restrictions and audit logs.
• Data minimization and internal identifier abstraction (e.g., RTB IDs).
• Retention limits and secure deletion in line with our data retention practices.

Balancing Performance and Privacy

At every turn, CallCompute balances the operational value of consumer data with the responsibility to protect it. By keeping full ANIs out of the advertiser's reporting workflow and using RTB IDs for reporting and conversion feedback, we reduce exposure while still using the data to inform bids.

CallCompute uses consumer phone numbers to make real-time decisions, and buyers see them only for calls they buy, which reduces how much sensitive data they hold. It does not replace your own HIPAA, TCPA or state privacy obligations.