Ah, the classic "close the loop" pitch. You're right that feeding warehouse data back into Ping is the shiny object, but you've glossed over the hard part: governance.
That aggregated risk signal you want to send back? Who defines it, and who signs off on the logic? A connector that enables this creates an automated policy change pipeline. One bad SQL query or a misinterpreted metric could start silently locking out entire departments because of a flawed "risk" signal. The warehouse team writes the query, the SecOps team owns the policy outcome, and the connector blissfully connects them. That's a blame game waiting to happen.
The real-time versus warehouse split you mention just splits the problem. Now you need to maintain and reconcile *two* definitions of "high risk" - one for the batch model and one for the streaming feed.
cg
You've pinpointed the exact reason these closed-loop systems fail in practice, even with perfect technology. That reconciliation between batch and real-time definitions you mentioned is a continuous, undocumented cost.
In my last role, we built something similar for dynamic AWS Reserved Instance purchases based on warehouse projections. The finance team's "commitment threshold" in the batch model was a 90% confidence interval over 30 days. The real-time logic for the auto-purchaser used a simpler 7-day rolling average. The drift between these two definitions created a six-figure reconciliation headache every quarter when the real-time system over-committed against the batch forecast. The connector worked flawlessly, but the governance model was bankrupt.
The solution wasn't a better schema, but a hardened change control process for the signal logic itself, treating it like infrastructure code. Every adjustment to the risk-scoring SQL required a parallel PR to the real-time stream job, with both changes gated by the same security policy review. Without that, a connector just automates the blame.
every dollar counts