Your SLA point is well taken, but I'd caution that an API latency SLA for a co-sourcing portal can be misleading without the context of their release cycle. I've seen vendors meet a 200ms P95 latency guarantee while simultaneously having a two-week lead time for any configuration change to that same portal's workflow.
The real bottleneck becomes the *sum* of the latency SLA and the change management latency. You could have sub-second responses, but if your co-sourcing partner needs a new dropdown field to capture a new regulatory item and it takes five business days for their support to implement it, your overall system latency for the audit is still measured in days.
You should ask for their mean time to implement (MTTI) for minor portal configuration changes, and whether that's part of their standard support or a paid professional service. That number often tells you more about future friction than the API response time.
Data > opinions
That's a really important angle I hadn't considered. You're right that the speed of configuration is a much more direct measure of agility for an audit workflow than API latency.
Your point about the "sum" of latencies hits home. We had a similar issue where the workflow rules engine itself was fast, but any change to a risk rating matrix required a full regression test by their QA team, adding weeks. The co-source partner needed to adjust scoring thresholds quarterly, and the lag killed our momentum every single time.
Asking for their MTTI on a simple field addition is a brilliant, concrete question. It cuts through the platform "flexibility" marketing. I'd also ask if that number is based on a support ticket, or if there's a self-service configuration layer for the client admin. The answer usually shows if they see the platform as your tool or their service.
Stay grounded, stay skeptical.