https://github.com/camaraproject/CustomerInsights/issues/23

DT

ON-HOLD

06/MAR: New Topic: Two levels of scoring precision in API.

DT brings this topic. Based on Czech republic business, there is two different levels of precision for the score (rough and detailed) with different prices, they have customer for both models. That is the business idea. And look for a technical solution for it.

TEF will check about this concept internally from business view. Also VF will talk internally about this concept.

20/MAR: TEF comments that business is aligned with the concept/idea of having different precision models in order to be able to monetize them with different API pricing. They do not see this concept as linked directly to a score model but to indicate different level of precision available for any scoring model, like a new input parameter that reflects the precision required. DT will share this internally to also get some feedback, also check how this is done in other WGs like device location, having different precision for the location of the device.

03/APR: Rafal will get information from Business side. As a comment a parameter could be accomodated in request to indicate the precision and if not indicated default precision is provided. Anyway, it is an observation and it is needed more details from Business before thinking in a technical solution. Also to check info from Operate APIs and TMF regarding the provision of a product and relationship to request a higher precision.

24/APR: DT is still pending to further check about this topic. DT comments another idea, if we consider scoring model as country specific, maybe indicate this scoring granularity based in some model in the response, but not sure if this would be needed.

15/MAY: No new information yet. Rafal is contacting Poland Operators to have feedback. Once he has compiled and consolidate this feedback WG can move forward with this discussion.

26/JUN - 09/JUL: No new information yet. Let’s keep ON-HOLD until having a resolution on this. Rafal is checking internally if the precision can be defined in the product (in the onboarding process, API Customer selects product (precision <-> price) and then there is no need for API parameter). Pedro will also check internally as talked offline. Kevin raises the good point of considering that as API consider two scales, one scale has wider range so it culd provide fine-grained score and in that way provide more precision. Also Pedro comments that this topic could be understood in two ways:

• Different scale provides a different score precision

• Score Precision is provided by different algorithm implementation over a same scale

Good point to follow-up discussion also with Rafal. To be discussed in the next meetings

31/JUL - 21/AGO: Kept On-HOLD, Rafal under investigation of API Provisioning flow (Onboarding process). Pedro comments about TEF Product Business view is more aligned to have a concept that indicates precision rather than use a scoringType associated to a specific precision.

04/SEP - 30/OCT: Rafal will make a reminder regarding this topic to their business (no feedback yet by business unit). WG will follow-up this topic within Spring26 MetaRelease

27/NOV: DT (Rafal) indicates therre is no new feedback from DT business side and he needs to finalize internal checks before seeing next steps for this issue.

11/DEC: No updates. Keep On-hold

https://github.com/camaraproject/CustomerInsights/issues/31

DT

ON-HOLD

24/APR: New issue opened by DT on 24/APR. It tries to manage the case in countries where there is personal identification number that changes when renewed but national identification number is kept from the first time it is generated (for instance this happens in Poland and it is a case in finantial procedures). It has also to discuss with Business Team. Some clarifications are commented by TEF, just to understand the topic. The “idDocument” concept refers to the national identification number that never changes (it is permanent) and in some countries the ID number of the document changes every time that document is renewed.
So probably some clarifications will have to be done regarding “idDocument” and also being checked by DT whether ID number of the document is also needed as optional for Use Cases within the context of this API. DT also will add some reference to wikipedia for this concept.
VF comments about the use of idDocument/phoneNumber. In Spring25, in 3-legged scenario no identification needs to be provided as API susbject is identified by the token. Thery are needed for 2-legged scenario and depending on Telco Operator rules (some Operators may only need phoneNumber, others both to perform a double-check to ensure is the same API Subject).

15/May: DT comments it is also pending to have information from Poland market, just to know whether both concepts would be required or only one (national identification number, i.e. idDocument). Rafal also comments about KnowYourCustomer/issues/197, where it is being discussed the support and indication of different idDocument types, just to have in mind for potential alignments. Pedro comments that even ID number of the document would not be required in the context of Customer Insights API, if idDocument description is modified in KYC we can align also in this WG to use the same description.

29/May: It is still pending internal feedback from DT. It seems it would be needed the new field, however no confirmation yet. In case the confirmation arrives after RC milestone it is commented it will not be a problem to include it, in order to consider for the Public Release.

12/JUN: No new information yet. Make reference to the issue opened in KYC Match KnowYourCustomer/issues/197. WG agrees on waiting up to how that topic moves forward in KYC Match group. Pedro indicates that reading the KYC Match issue has detected that “idDocument” concept was indeed the concept of inmutable person identifier (national identification number) and now it seems is being interpreted as the (Document ID number - temporal one that changes every time documentation is renewed) so it is exchanging the role with the new attribute proposed.

26/JUN - 21/AGO: No new information yet. Let’s keep ON-HOLD until having a resolution on this. Rafal is still waiting business feedback.

04/SEP - 30/OCT: Rafal will make a reminder regarding this topic to their business (no feedback yet by business unit). WG will follow-up this topic within Spring26 MetaRelease

27/NOV: DT (Rafal) indicated this parameter is used in some markets (e.g., Czech Republic) and may need to be added as optional. Pending confirmation from DT business before modeling changes in the specification and moving forward.

11/DEC: No updates. Keep On-hold

https://github.com/camaraproject/CustomerInsights/issues/59

TEF

ON-HOLD

16/OCT: Issue Raised by TEF:

• Concern about reusing transversal exceptions (e.g. mismatched identifiers) across APIs like Customer Insights and Know Your Customer Match.

• TEF business prefers distinct exceptions to avoid potential misuse or false positives where an API consumer might exploit pricing differences between APIs.

• A new issue was opened to reflect this concern and propose a separate exception for Customer Insights.

Security & Fraud Considerations

• Vodafone (Kevin) raised concerns about potential fraudulent use of the API:

  • Risk of brute-force attempts to match ID documents with phone numbers.

  • Suggested using generic error messages to avoid exposing sensitive validation logic.

  • Emphasized the need for backend monitoring and rate-limiting to detect suspicious behavior.

• TEF (Pedro) acknowledged the concern and indicated to:

  • Investigate current backend behavior in place.

  • Continuing internal checkings and come back to follow-up the discussion.

30/OCT: After internal checking, Pedro (TEF) indicates there is no correlation between ‘phoneNumber' and 'idDocument’ in business logic for the 2-legged scenario. That means the exception is not triggered in 2-legged case. Besides this, TEF is internally checking with their business and KYC team as there are similar situations in KYC-Match. Therefore it is proposed to set the issue On-Hold until reaching an internal conclusion on it. Kevin and Rafal also follows KYC subproyect so all will be synched.

27/NOV: After internal aligment TEF (Pedro) has proposed removing specific exceptions (e.g., ID document mismatch, a.k.a. 422 CUSTOMER_INSIGHTS.INVALID_IDENTIFIERS and checking internally 422 CUSTOMER_INSIGHTS.ID_DOCUMENT_REQUIRED) and using a generic “422 SERVICE_NOT_AVAILABLE” error to avoid exposing sensitive logic and prevent fraudulent scenarios. Some rationale is aligment with KYC-Match camaraproject/KnowYourCustomerMatch/issues/49.
Initial feedback:

• VF (Kevin) supported the approach for better API usability and security.

• DT (Rafal) suggested considering local market requirements where explicit errors might still be needed.

Next steps: Continue internal checks and revisit in the next meeting.

11/DEC: Pedro has shared with TEF business product in order to get their detialed view in this proposal. It is waiting for their assesment. Hope to have in the next week. It will be reflected in the Issue, so let’s keep on hold until this feedback in ordert o check next steps.

https://github.com/camaraproject/CustomerInsights/issues/61

RM action

ONGOING

10/DIC: A PR has been generated to cover openapi definition files PR#60, and associated to the issue. It has been updated today to include missed servers.url update to vwip.

Rafal explains this initiative comes from Herbert under the umbrella of RM in order to have some automation to detect this RM action when applicable, and in future it could be enhanced to also generate the PR automatically.

Taking advantage of the issue, PR has been generated today to also cover Test Definitions part PR#62.

Review of these PRs is kindly requested for approval and merge.

AoB

WG

Talk about next meeting:

• Pedro comments to wait until the next week in order to manage next meeting (due to pending holidays to be scheduled)

• Meeting on December, 25th will not take place.

• Next Meeting on January, 15th