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

1. 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.

2. Fraud Hotzone ReportAPI 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
#243

[eric-murray]

Hi @Ma-Guang-Han

So is the proposal simply to return a security risk score based on phone number (so a bit like Customer Insights, but returning a security rather than credit risk score, and only accepting phone number as the customer identifier), or is the proposal more complicated than that.

if the proposal is more complicated than simply retrieving a pre-computed security risk score, can you elaborate?

Thanks

[Ma-Guang-Han]

Hi @eric-murray

The Communication Risk Check API does not return a security risk score. Instead, this API provides detailed information about the queried phone number. For example:

The count of total calls dialed (or received) by the calling (or called) party number

The count of international calls dialed (or received) by the calling (or called) party number

The country names from which the calling (or called) party number was dialed (or received)

The count of total SMS messages sent (or received) by the calling (or called) party number

The count of international SMS messages sent (or received) by the calling (or called) party number

The country names from which the calling (or called) party number sent (or received) SMS messages

The purpose of this API is to allow API consumers to check a specific number’s call and SMS activity patterns, helping them determine whether the number may be used by a fraudster or whether it may be a potential fraud target being prepped for a scam.

This API functions differently from Customer Insights. It allows users to query phone numbers that may belong to potential fraudsters or fraud victims, and it provides detailed call and SMS data to help the API consumer determine whether a number should be treated with caution or flagged for further attention.

Thank you!

[eric-murray]

OK - so the API will provide all the raw metrics to the API consumer, who can make up their own mind as to the risk.

The question in my mind is then why would any customer agree to share their data in this way? A "risk score" might be justified on the basis of fraud prevention, but the raw data would require the owner of the queried phone number to actively agree to share it.

[cht-jhc]

Hi @eric-murray, thanks for your comment!
We consulted our relevant departments at Chunghwa Telecom regarding user privacy regulations and learned that when users sign mobile network (4G/5G) contracts, the agreement includes a statement informing them that their data may be accessed for legitimate reasons such as fraud prevention, in order to protect their safety.
I believe that certain APIs, such as Device Location Retrieval, may also encounter similar user privacy issues. However, the ongoing discussions around Consent Management might help address this.

We chose not to use a "risk score" primarily because API users tend to perceive it as being based on a wide range of criteria, which can blur the focus. Some also view it as a black-box calculation. Instead, we maintain flexibility so that API users can apply it more conveniently in their fraud prevention use cases.

[tanjadegroot]

Adding the comment I made on the API Backlog call here as well:

using the term "Alert" in the new proposed name (Fraud Hotzone Alert) sets the expectation that this is a subscription API (with notifications).
However, the proposed API has a request - response pattern. Note: possibly an asynchronous response (using a callback) would be needed in case of longer processing time to calculate the result.

The suggestion is to

• use "Report" or "Information" in the name rather than "Alert" or just use "Fraud Hotzone" API.

In addition on the design you could

• design the API such that the schemas used in the request (e.g. "fraudHotzoneReportDescriptor" in the below example) and in the response (e.g. "fraud-hotzone-report" in the below example) could also be used (in the future) in a subscription and an event structure definition of a subscription API.

example

for a one time report API with synchronous response (immediate report)
POST /fraud-hotzone/v0.1/check (fraudHotzoneReportDescriptor)
-> response (fraud-hotzone-report) -

or

for a one time report API with asynchronous response (that needs processing time)
POST /fraud-hotzone/v0.1/check (fraudHotzoneReportDescriptor, callbackUrl)
-> resulting in (a single) response (fraud-hotzone-report) being posted on the callback

in a later version adding a subscription API:
POST /fraud-hotzone-subscriptions/v0.1/report-descriptors (fraudHotzoneReportDescriptor, callbackUrl)
-> resulting in: cloudevents (fraud-hotzone-report) being posted on the callback

NOTE This is just an example to illustrate my point on the naming. API designers can probably improve on this :-)

[Ma-Guang-Han]

Adding the comment I made on the API Backlog call here as well:

using the term "Alert" in the new proposed name (Fraud Hotzone Alert) sets the expectation that this is a subscription API (with notifications). However, the proposed API has a request - response pattern. Note: possibly an asynchronous response (using a callback) would be needed in case of longer processing time to calculate the result.

The suggestion is to

• use "Report" or "Information" in the name rather than "Alert" or just use "Fraud Hotzone" API.

In addition on the design you could

• design the API such that the schemas used in the request (e.g. "fraudHotzoneReportDescriptor" in the below example) and in the response (e.g. "fraud-hotzone-report" in the below example) could also be used (in the future) in a subscription and an event structure definition of a subscription API.

example

for a one time report API with synchronous response (immediate report) POST /fraud-hotzone/v0.1/check (fraudHotzoneReportDescriptor) -> response (fraud-hotzone-report) -

or

for a one time report API with asynchronous response (that needs processing time) POST /fraud-hotzone/v0.1/check (fraudHotzoneReportDescriptor, callbackUrl) -> resulting in (a single) response (fraud-hotzone-report) being posted on the callback

in a later version adding a subscription API: POST /fraud-hotzone-subscriptions/v0.1/report-descriptors (fraudHotzoneReportDescriptor, callbackUrl) -> resulting in: cloudevents (fraud-hotzone-report) being posted on the callback

NOTE This is just an example to illustrate my point on the naming. API designers can probably improve on this :-)

Thank you very much for sharing your experience and for your professional advice. Over the past few days, we’ve discussed your suggestions with our management team and API technical team, and we’ve made sure to pass along the information you provided.
After careful consideration, we’ve unanimously decided to adopt your recommendation to rename our API to Fraud Hotzone Report. We also plan to take your proposed endpoint design as a reference for our future implementation and roadmap.
Both our management and API design teams agree that your suggestions and direction align much better with the standardized approach and format used in the CAMARA Project — which is exactly what we aim to achieve.
We truly appreciate your valuable input.

[hdamker]

After looking across the documentation, especially the ppt document uploaded within https://github.com/camaraproject/APIBacklog/pull/243/files, I'm very convinced that this API proposal is in the same category as ScamSignal, which is for good reasons a non-public API.

Providing the raw data is not an option from privacy and telecommunication secrecy point of view (at least not without a law enforcement title), which also the API proposal owner has agreed. Providing just an information about some detected anomaly would definitely require a description about how the input variables are processed to achieve comparable implementations - which is exactly the reason why ScamSignal can't be defined in public as otherwise it will give fraudsters the information they need to avoid the detection of such anomalies.

My vote would be therefore to either develop this API market specific (considering the local regulation and context) or ask GSMA to host the API definition in the same way like they are doing for ScamSignal (which makes sense as the proposed API is complementary to it).

[Ma-Guang-Han]

After looking across the documentation, especially the ppt document uploaded within https://github.com/camaraproject/APIBacklog/pull/243/files, I'm very convinced that this API proposal is in the same category as ScamSignal, which is for good reasons a non-public API.

Providing the raw data is not an option from privacy and telecommunication secrecy point of view (at least not without a law enforcement title), which also the API proposal owner has agreed. Providing just an information about some detected anomaly would definitely require a description about how the input variables are processed to achieve comparable implementations - which is exactly the reason why ScamSignal can't be defined in public as otherwise it will give fraudsters the information they need to avoid the detection of such anomalies.

My vote would be therefore to either develop this API market specific (considering the local regulation and context) or ask GSMA to host the API definition in the same way like they are doing for ScamSignal (which makes sense as the proposed API is complementary to it).

Hi @hdamker ,
Does this mean we need to respond to this topic in the next API Backlog meeting, and not discuss it in the TSC meeting, right?

In addition, what does “develop this API market specific (considering the local regulation and context)” mean?
Does it imply that this API can still be categorized under CAMARA’s GitHub?
If so, how would it differ from the other APIs that are also categorized under CAMARA’s GitHub?

[hdamker]

Does this mean we need to respond to this topic in the next API Backlog meeting, and not discuss it in the TSC meeting, right?

Yes.

In addition, what does “develop this API market specific (considering the local regulation and context)” mean? Does it imply that this API can still be categorized under CAMARA’s GitHub? If so, how would it differ from the other APIs that are also categorized under CAMARA’s GitHub?

My general thought is, that it doesn't fit into a public repository and project like CAMARA for the stated reasons, and that other options should be considered for it.