Open APIs

TMF APIs for Credit Risk Evaluation Architecture

Hello everyone.

We are currently redefining our architecture for customer credit evaluation.
At present, we have a Credit Risk Management Platform that is queried by different channels to obtain customer credit approval. In a future scenario, we believe this platform could be accessed via TMF696 (Risk Management).

This platform, in turn, queries several systems to make the credit decision:

1. Master Financial System
• Holds all the customer's financial information.
• We believe this could be integrated using TMF678 (Customer Bill Management).
  Question: Is TMF678 the correct API for retrieving detailed financial account information from a master system?
2. External Financial Data Provider (credit bureau).
• Provides purchased financial data about the customer.
• We decided to use TMF632 (Party Management) because we buy customer data from this provider.
  Question: Is TMF632 the right choice for this scenario, or should we consider another API for external data acquisition?
3. Calculated Indicators System
• Returns computed metrics based on multiple master systems (e.g., sum of unpaid financed installments, number of leased financed devices, total financing used).
• We believe TMF717 (Customer 360 Management) could be suitable, as it aggregates customer information from different sources. Another option might be TMF628 (Performance Management).
  Question: Which API is best suited for exposing aggregated or calculated customer indicators? TMF717 or TMF628?

Additional Question:
Would TM Forum recommend a specific pattern or API orchestration approach for this type of multi-source credit evaluation scenario?

Please find below a diagram for better understanding

Thank you, best regards.

------------------------------
María soledad Alfonso
Entel Chile
------------------------------

Hi,

I suggest revisiting previous discussions on credit check. You may find useful perspectives, scenarios, and designs that other telecom companies have already explored.

Below are a few points from my experience.

In telecom, a Product Offering can be sold as a recurring charge (postpaid) or as a one-time charge (prepaid). A recurring charge represents a subscription.

• Prepaid offers do not require a credit check.

• Postpaid offers usually require a credit check, although this remains the seller's decision.

Credit check is strongly linked to pre-order flows and belongs in the commercial Eligibility domain.

My design is based on TMF679 Product Offering Qualification, not TMF696, and also follows the ODA blueprint principles.

At design time

• The Product Catalogue contains Product Offerings.

• Each Product Offering references a credit check rule through a policyRef.

At runtime

• Engagement Management, such as a webshop, invokes TMF679 with a POST request.

• TMF679 retrieves the Product Offering from TMF620 and obtains its policyRef.

• TMF679 then calls the credit risk management service, supplying the relevant context, for example policyRef and customer id. (different options exist here)

• TMF679 receives the result, evaluates any additional catalogue rules, and determines eligibility.

• TMF679 returns a response to the engagement layer with an eligibility status per Product Offering as well as per business rule (array of ineligibility reasons). Credit check outcomes can appear as specific ineligibility reasons.

The user experience is flexible. You may hide ineligible offers, display them with an explanation, allow adding to the cart but block order submission, and so on. The front end can also decide how to present these outcomes and guide the customer with next steps.

My knowledge is not solid enough to comment on all customer and financial TMF APIs but there sure is quite a lot of them at TM Forum!

My two cents,
Matthieu

PS: In future you could consider adopting a BRMS with TMF723 to maintain business rules such as credit check. TMF679 would still retrieve the rule content, fetch the required data, and compute the actions and outcomes. The alternative is to delegate all rule evaluation to an external universal rule engine, with TMF679 acting as a orchestration layer (our implementation has a hybrid model: 679 computes rules and delegate some rules to 3rd party APIs but the response to the client would be aggregated).

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
------------------------------