“I meant what I said and I said what I meant”
As someone who has worked on so many RFPs over the years it always amazes me the incredible nuance that is required when talking about software systems. I’ll use credit and fraud decisioning as my example but I’m sure it’s true for other systems as well.
Let’s take a simple example. “Does the loan origination system work with machine learned models?”
On the surface it seems like such a simple question but there is a lot of nuance for the words “work with.”
For example, I could request that the machine learned model (ML for short) output value is passed in the API request to the decisioning system. Really at that point it is no different than any other value passed in (numeric or otherwise). Most systems should be able to do this.
It could mean that the loan origination system does a callout to an ML server (something like DataRobot) and uses the value that comes back. In this case the key is an ability to callout to another system. The fact that the other system is an ML server is kind of immaterial to the caller (the loan origination system). Basically you make a call to another service and get some values back. The key here is the remote call.
Another example might be a native capability to calculate the ML model from directly within the loan origination system. Perhaps the loan origination system has a capability to natively host the ML model within it. This might take the form of a R, Python or other language execution capability directly within the system. In this case there is no need to “call” another system.
Lastly, a user might mean that the vendor’s solution can not only execute an ML model but also train it as well. Personally I doubt many clients would believe this but it is possible that some will. Training any kind of model (ML or otherwise) is far beyond the traditional capabilities of a loan origination system. Usually I’d expect the vendor to provide another tool for this purpose.
All of these capabilities can be categorized as supporting ML execution but there are vast differences in how these systems are architected and built. I’ve seen many situations where both the vendor and the client thought they were saying the same thing only later to learn the vast gulf in their understanding. Reconciling these misunderstandings is always costly in both time and budget. This is just one easy to explain example but there are many others just like it. Please reach out to peter.j.accorti@gmail.com if you want to discuss these kinds of issues.
