Open APIs

Is there an OOTB operation or mode of adding more Risk Categories, Risk Types (current examples of Product Offering Risk Types are FraudRisk, BadPaymentRisk, CreditGamingRisk, IDConfidenceRisk, PaymentMethodRisk) in the existing categories than the default ones mentioned in the API. Or do we need to extend the API to add this operation.

Thanks in advance for any support. 

Short answer, as far as the spec goes: TMF696 doesn't give you a taxonomy-admin operation. It's an assessment API - you ask for a risk assessment and get a verdict back - not a catalogue API for the risk types themselves. So the values you listed behave as an extensible enumeration, and there's nothing out of the box that lets you POST a new risk type the way you'd POST a Category in TMF620.

Which means the real question isn't "extend the API or not". It's where the taxonomy lives - and that's worth settling before you write the extension.

If you extend the enumeration in the spec, adding a risk type becomes a schema change: new version, new contract, regression on every consumer, a deploy. That's fine for something that moves once a year. Risk types don't. They move when a new fraud pattern shows up, and the people who need the new type are usually asking for it inside the same week. If the answer is "next release", what actually happens is that the risk team quietly encodes three new meanings inside the characteristic bag of an existing type, and a year later nobody can tell you what BadPaymentRisk means, because it's four things.

So the shape I'd argue for: keep the standard values as the interoperable contract, and treat the operator-specific taxonomy as reference data with its own lifecycle - an id, an owner, an effective-from date, a deprecation state - that risk types resolve against. The enumeration then only carries stable, genuinely shared concepts, and the volatile part moves at the speed the fraud team needs.

Two things worth checking before you decide. First, whether any consumer branches on the risk type string. If an order-capture or dunning rule matches on it, an "additive" new type is not additive - it's a silent no-match on a decision path, and it fails open. Second, retention: an assessment taken in March under a definition you retired in June still has to be explainable in a dispute, so definitions need to be versioned, not overwritten.

What change cadence are you actually designing for - a handful of new types a year, or a moving target?

Thanks a lot Raunak for the recommendations.