Integration build · Enterprise · 2024
Verity Compliance
An enterprise risk team needed six data sources in one review queue. Procurement took longer than the build did.
- Rails
- PostgreSQL
- Sidekiq
- SAML SSO
- 6
- source systems unified into one review queue
- 70%
- reduction in time to close a vendor review
- 0
- findings in their internal security review
The challenge
A compliance team at a mid-market financial services firm assembled every vendor review by hand from six systems — two internal databases, three vendor APIs, and a shared drive of PDFs. Analysts spent the majority of their time gathering information rather than assessing it.
What made it hard
-
Six sources, six different reliability profiles
Two of the vendor APIs were rate-limited and one went down for scheduled maintenance weekly. The system had to keep being useful when a source wasn't available.
-
Security review before a single line could reach production
Single sign-on, encryption at rest, audit logging, and data retention rules were entry requirements rather than follow-up work.
-
Their process was the requirement, not a starting point
Analysts followed a review workflow tied to their regulator's expectations. We had to fit it exactly, including the parts we might have designed differently.
What we built
-
1
Built ingestion as independent, retrying jobs
Each source syncs on its own schedule and fails on its own. A vendor outage degrades one panel instead of taking down the queue, which is the difference between a tool analysts trust and one they work around.
-
2
Cached aggressively, with freshness always visible
Analysts see the data plus when it was last synced, so they know what they're looking at instead of guessing whether it's current.
-
3
Met the security requirements in the first sprint
SAML single sign-on, encryption at rest, a complete audit trail, and configurable retention. Their review passed with no findings, which is why launch wasn't delayed.
-
4
Modeled their workflow exactly as it existed
Their review stages, their approval chain, their terminology. We proposed no process improvements until they had used it for a full quarter and could judge suggestions from experience.
-
5
Worked inside their process, not alongside it
Their sprint cadence, their code review, their change management. We operated as another team rather than an outside vendor with a separate plan.
Fitting into an enterprise without slowing it down
The fear with a small agency at enterprise scale is reasonable: that we won’t survive contact with procurement, security review, and change management, and that the project will stall in a process we don’t understand.
The way through it is to treat those requirements as design inputs from day one instead of obstacles discovered at the end. Single sign-on and audit logging in the first sprint cost us a week. Retrofitting them after a failed security review costs a quarter, because by then the data model has assumptions baked in that the requirements don’t allow.
The same goes for their review workflow. We had opinions about a couple of their approval stages. We kept them to ourselves until the team had used the system for a quarter — at which point they raised one of the same points themselves, from a position of actually knowing. Suggestions land very differently when they come after you’ve earned the right to make them.
“They passed our security review on the first submission. I have not been able to say that about an outside vendor before.”
Got something that looks like this?
Thirty minutes, no pitch. We'll tell you what it would actually take.
Book a free 30-min callRather not book a time? Send a message instead.