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: No new information yet. Let’s keep ON-HOLD until having a resolution on this

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: No new information yet. Let’s keep ON-HOLD until having a resolution on this

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

WG

ONGOING

15/MAY: Parent issue for Metarelease Fall 25 activities generated.

26/JUN: Pull Requests to address M3 were generated on 16th June Week. First two ones need WG approval prior to align Release Candidate PR and remove DRAFT.

• API Specification alignment with Transversal WGs: https://github.com/camaraproject/CustomerInsights/pull/43

• Gherkin Features Updates: https://github.com/camaraproject/CustomerInsights/pull/44

• Release Candidate (DRAFT, above ones need to be approved and merge in advance): https://github.com/camaraproject/CustomerInsights/pull/45

Commented the 3 PRs during the meeting to explain the rationale for their review. The first two ones are kindly requested for review and approval this week in order to align RC Pull Request and generate final version for Release Management review next week.

AoB

WG

Talk in the next meeting about summer meetings scheduling