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

15/JAN: Rafal will synchronize this topic internally with DT CAMARA technical staff and also Business side. Hope to have news soon.

05/FEB: Rafal indicates No new updates from business side. The topic remains on hold until clearer business definitions are available. Decision: keep the issue on hold and resume once definitions and requirements are better defined.

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

DT

CLOSED

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

15/JAN: Rafal will synchronize this topic internally with DT CAMARA technical staff and also Business side. Hope to have news soon.

05/FEB: DT (Rafal) confirmed that, for now, the phone number is the primary identifier. National identification number could provide additional demographic insights (e.g. date of birth, gender) in some markets (e.g. Poland), but this is currently out of scope. The WG agreed that the identifier is not required at this time. Next Actions:

• Rafal will add a final comment summarizing conclusions.

• Issue will be closed after the comment is added.

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

TEF

ONGOING

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

15/JAN: Pedro provides the consolidated feedback by Bussiness in this comment. Basically:

• Replace 422 CUSTOMER_INSIGHTS.INVALID_IDENTIFIERS and manage the scenario with 422 SERVICE_NOT_APPLICABLE.

• Replace 422 CUSTOMER_INSIGHTS.ID_DOCUMENT_REQUIRED by 422 SERVICE_NOT_APPLICABLE as well.

Kevin asks about the scenario when an Operator does not support idDocument and API Consumer provides it. For that scenario, API defines the 422 CUSTOMER_INSIGHTS.ID_DOCUMENT_NOT_SUPPORTED scenario. Initially the proposal looks fine for him.

Rafal indicates the need to check this proposal internally and also related to KYC-Match behaviour and provide feedback.

05/FEB: TEF asks for comments about provided approach. VF confirmed alignment with this approach. DT confirmed no objections and agreed to proceed. Next Actions:

• TEF will prepare a draft Pull Request implementing the agreed changes.

• The PR will be reviewed by the WG once submitted.

AoB

WG

API Quality & Commonalities Alignment

Proposal to align Customer Insights API with Commonalities linting and validation rules (e.g. OWASP / Spectral rules).

• Objective: improve API design consistency (string lengths, numeric formats, constraints).

• Agreement to open a new issue to discuss and define API-specific recommendations.

• DT will explore automation options to detect and enforce missing constraints.

• Next actions:

  • A new issue will be opened within the WG to start the discussion.

  • Automation and common definitions will be explored in parallel.

Trial in UK by VF
Kevin shared VF plans for an offline trial of the scoring algorithm using a large dataset (2–3 million UK numbers). Results are expected around end of March. Findings may serve as a valuable case study for the WG.

February, 19th 2026 -- 14:00 - 15:00 UTC (15:00 - 16:00 CET)

Meetings Link

March, 5th 2026 -- 14:00 - 15:00 UTC (15:00 - 16:00 CET)

Meetings Link