New API Proposal - Fraud Hotzone Report

[Ma-Guang-Han]

API Proposal: Fraud Hotzone Report API

Description
Fraud Hotzone Report API empowers anti-fraud systems to analyze phone call and SMS activities associated with a phone number during a specified period, offering a comprehensive view of communication behavior.

The API provides multiple indicators and detailed insights related to phone call and SMS interactions. These insights enable banks, government agencies, and other API consumers to identify suspicious patterns more effectively. It enhances fraud prevention by supporting both suspect detection and victim protection.

Use cases

Fraud Hotzone Report API helps banks enhance real-time risk detection of incoming calls when bank customers receive suspicious scam calls during money transfers, effectively preventing fraud. ​
With this API, banks can detect abnormal changes in past communication behavior to determine whether the caller may be a potential scammer.

Fraud Hotzone Report API helps banks detect potential fraud when customers request large withdrawals. If suspicious behavior arises, staff can query the customer's communication data. ​
Using this API, they can detect abnormal changes in the customer's communication behavior to assess whether they might be potential victims.

Related to
#241

[albertoramosmonagas]

I am using the comments of the proposal to post the questions that came up in the WG Backlog session of 2025-07-10.

Consent & Privacy

1. How is end-user consent obtained?

• Is consent explicitly included in the mobile service contract?
• Is that consent valid for sharing sensitive data like call/SMS volume and origin information?

2. How is GDPR (or other local privacy regulations) compliance ensured?

• Can users opt out or revoke consent?
• How is third-party data handled (e.g., the recipients of calls or SMS)?

3. What privacy safeguards are applied to the data being shared?

• Is the information anonymized or aggregated?
• What measures are in place to prevent re-identification?

Scope and API Design
4. How does this API differ from similar initiatives like Scam Signal or Customer Insights?

• Is there any overlap or redundancy?
• What is the unique value proposition?

5. Is it possible to return a simplified output (e.g., a risk score: high/medium/low) instead of detailed data?

• Would this approach be more aligned with privacy expectations in regulated markets?

6. Could the API offer a “lightweight” mode, only returning key indicators instead of detailed breakdowns?

Adoption & Market Fit
7. Has the API been validated outside of the local market (e.g., Europe, Africa)? Are there legal or regulatory barriers in those regions?
8. Have banks or potential API consumers provided feedback confirming their need for this solution? Is there any documented interest or demand?

I put in copy of the thread to those who were in the discussion @eric-murray, @tanjadegroot

[eric-murray]

My concern would be relying on contract as the lawful basis for sharing this level of information is that pointing to some vague clause in the contract about "using data for fraud prevention purposes" and then saying to the customer "well, you agreed to it" is not a good look.

Whilst I agree that if the end customer has "consented" to sharing this data (and for GDPR and similar, that is a high hurdle), then it's fine to share, my concern is that APIs such as this will make CAMARA look like a "privacy intrusive" organisation.

CAMARA APIs are intended for "general consumption" for any API consumer who can get the informed consent of the telco customers. If it is considered that this API is only applicable to a very narrow subset of API consumers (e.g. banks) and would never be offered for general consumption, then the GSMA route might be better.

I would certainly welcome the GSMA's opinion on this proposal.

[Ma-Guang-Han]

Hi @eric-murray

May I ask if the GSMA route refers to something like the Scam Signal API? Is this API not categorized under CAMARA APIs but instead classified as a GSMA Open Gateway API?

What’s the difference between Scam Signal and CAMARA APIs?
For example, are the developers not from the proposing telecom operator? Or are there different specifications or development processes?

[Ma-Guang-Han]

Hi, @albertoramosmonagas @eric-murray @tanjadegroot

After our last meeting, our manager had a follow-up discussion with our partner bank and the technical team working on this API. We feel the current API name could better reflect what the API actually does.
This API is mainly used to analyze whether a user's calling or messaging behavior is abnormal, and it evaluates communication data by country to see if there's a sudden spike in activity with high-risk or fraud-prone regions.
Because of that, we believe “Fraud Hotzone Alert” is a better fit than “Communication Risk Check”—it more clearly describes the API’s real purpose.

We’ve also made changes to the API’s input and output based on the issues discussed in the last meeting.
For details, please refer to the slide deck I uploaded. Looking forward to discussing with you in today’s meeting. Thank you!

[albertoramosmonagas]

After our last meeting, our manager had a follow-up discussion with our partner bank and the technical team working on this API. We feel the current API name could better reflect what the API actually does. This API is mainly used to analyze whether a user's calling or messaging behavior is abnormal, and it evaluates communication data by country to see if there's a sudden spike in activity with high-risk or fraud-prone regions. Because of that, we believe “Fraud Hotzone Alert” is a better fit than “Communication Risk Check”—it more clearly describes the API’s real purpose.

We’ve also made changes to the API’s input and output based on the issues discussed in the last meeting. For details, please refer to the slide deck I uploaded. Looking forward to discussing with you in today’s meeting. Thank you!

Thanks for the update and for sharing the rationale behind the proposed name change.

We understand the reasoning behind moving from “Communication Risk Check” to “Fraud Hotzone Alert”, as it indeed better reflects the API’s function of identifying abnormal communication patterns with high-risk geographies.

If the decision is made to proceed with the new name, we kindly ask that it be reflected consistently across the issue title, pull request title, and any relevant content, to ensure traceability and alignment across teams.

Thanks again.

[Ma-Guang-Han]

After our last meeting, our manager had a follow-up discussion with our partner bank and the technical team working on this API. We feel the current API name could better reflect what the API actually does. This API is mainly used to analyze whether a user's calling or messaging behavior is abnormal, and it evaluates communication data by country to see if there's a sudden spike in activity with high-risk or fraud-prone regions. Because of that, we believe “Fraud Hotzone Alert” is a better fit than “Communication Risk Check”—it more clearly describes the API’s real purpose.
We’ve also made changes to the API’s input and output based on the issues discussed in the last meeting. For details, please refer to the slide deck I uploaded. Looking forward to discussing with you in today’s meeting. Thank you!

Thanks for the update and for sharing the rationale behind the proposed name change.

We understand the reasoning behind moving from “Communication Risk Check” to “Fraud Hotzone Alert”, as it indeed better reflects the API’s function of identifying abnormal communication patterns with high-risk geographies.

If the decision is made to proceed with the new name, we kindly ask that it be reflected consistently across the issue title, pull request title, and any relevant content, to ensure traceability and alignment across teams.

Thanks again.

Thank you for the reminder. We have already updated the title, content, Markdown file, and presentation regarding the API name!

[jgarciahospital]

LGTM