Skip to main content
VSI Technologies

Document work that closes faster and audits clean.

Origination, document processing and controls that survive an examination.

Industry overview

Inside a financial services operation

Cycle time is dominated by document handling: collecting, checking, chasing and re-checking. Every handoff adds days, and the controls that keep an examiner satisfied are the same controls that make the process slow. Nobody wants to trade one for the other, so the process stays.

Almost none of the elapsed time in an origination is work. It is waiting, for a document to arrive, for a check to be performed, for an exception to be routed to somebody with authority, for a second person to review what the first person did. The actual processing time is a fraction of the cycle time, which is why adding staff produces less improvement than anyone expects.

Document handling is where the waiting concentrates. A file arrives incomplete, which is discovered by a person reading it, who then requests what is missing, which arrives days later and is also incomplete. Each of those cycles is a customer experience as well as a cost, and in a competitive origination market the cycle time is frequently the reason a deal goes elsewhere.

The control environment is not the problem, though it is usually blamed. Dual review, exception routing and audit trails exist because an examiner will ask, and removing them to go faster is a trade nobody sane makes. The waste is not in the controls themselves; it is in the manual assembly of the evidence that the controls were followed, and in the human effort spent re-reading documents to check things a machine can check reliably.

Reporting sits on top of all this, assembled by hand from several systems on a cycle, with definitions that vary slightly depending on who built which return. Regulatory and internal reporting draw from overlapping data with different rules, and reconciling them is somebody’s recurring week.

The thing that makes this sector distinctive is not the volume; it is that an examiner will ask how a decision was reached and expects a coherent answer. That single requirement rules out any design where a model’s output is the decision, and rules in a design where the model narrows and evidences and a person decides.

Common challenges

Challenges we see across financial services

If three or more are true, the rest of this page is about your operation.

  • Cycle time is dominated by waiting, not processing
  • Incomplete files are discovered by a person reading them
  • The same document gets checked by two people for different reasons
  • Regulatory and internal returns draw on the same data with different definitions
  • Exception handling depends on knowing who to ask rather than on a defined route
  • Producing an audit trail for an examination is a project rather than an export

How we help

Five practices, applied to financial services

AI, cloud, cybersecurity, hardware and programme delivery, one integrated bench, each practice applied to how financial services actually operates.

  1. Agents for the document-heavy middle of lending and onboarding: condition clearing in Encompass, income and asset document classification, exception queues in nCino, and complaint intake routed with the full audit trail your compliance team needs at examination time.

  2. Data architecture that makes automation possible at all: warehouse consolidation on Snowflake, integration between the core, the CRM and the servicing stack, and environments segregated so model development never touches production customer data uncontrolled.

  3. Controls built for a regulated balance sheet: privileged-access management on the systems that move money, logging that satisfies books-and-records obligations, and vendor-risk documentation for every component we introduce, written for your examiners, not just your engineers.

  4. Branch and back-office fleets refreshed without disrupting the teller line: imaging to your hardened builds, encrypted-at-rest endpoints, and disposal with certificates of destruction your audit team can file.

  5. Delivery under model-risk governance: documentation of what the system does and why, validation checkpoints written into the plan, and change control that keeps the second line of defence informed rather than surprised.

Where we start

Automation candidates

Deliberately mundane. The impressive-sounding workflow is rarely the one worth doing first.

  • Origination: document collection, completeness checking, exception routing
  • Underwriting support: extraction and cross-checking against submitted files
  • Client onboarding: identity, documentation and periodic review
  • Reporting: regulatory and internal returns assembled from several systems
  • Correspondence: drafted responses with an audit trail attached

Systems we integrate with here

If you run one of these, this is the conversation.

  • Encompass
  • Salesforce
  • nCino
  • Temenos
  • Snowflake

Our solutions

How we transform financial services operations

What happens today, what changes, and what to watch for as each workflow is automated.

Origination

Today
A file arrives, a person reads it to find out what is missing, requests it, and the cycle repeats. Exceptions get routed by asking someone who knows.
After
Completeness checked on arrival against the requirement set for that product, the specific missing items requested immediately in one message rather than three, and exceptions routed by defined rule to the role with the authority, with the routing decision recorded.
What to watch
A completeness check is not an underwriting decision and the boundary has to be explicit in the interface. The moment staff start treating a green completeness flag as approval, the control has been quietly removed.

Underwriting support

Today
Figures are extracted from submitted documents by hand and cross-checked against the application, which is careful, slow, and exactly the work attention degrades on.
After
Extraction with the source location retained for every figure, and cross-checks between documents surfaced as discrepancies for the underwriter, who now reads a list of things that do not agree rather than everything.
What to watch
Every extracted figure must be traceable to where it came from in one click. An extraction the underwriter cannot verify against the source is one they will re-do manually, which is worse than not having it.

Client onboarding

Today
Identity and documentation collected over several exchanges, then periodic review handled as a campaign when it falls due, usually late.
After
Structured collection with validation at the point of submission, and periodic review worked continuously against due dates rather than in an annual scramble.
What to watch
Identity verification decisions carry regulatory weight and stay with a person. What is automated is the collection, the validation and the chasing, not the judgement.

Reporting

Today
Returns rebuilt each cycle from several systems, with definitions that drift depending on who built which one.
After
Assembled on schedule against agreed definitions, with variances beyond a threshold flagged for review before submission and the lineage of each figure available.
What to watch
Definitions must be agreed and written down first. Automating a return whose definitions are contested produces a fast, consistent, disputed number and an examination finding.

Correspondence

Today
Responses drafted from precedent that somebody has to find, with the audit trail assembled separately if at all.
After
Drafted from approved language with the case facts inserted, and the trail, what was said, on what basis, approved by whom, captured as a by-product rather than as a separate task.
What to watch
Anything that is a complaint, a dispute, or subject to a regulatory clock must be recognised and escalated rather than answered. The classifier has to fail toward escalation.

The operating picture

Where the agent layer sits in the lending pipeline

Your operating loop todayThe agent layer we deploy into it
01

Application

Borrower documents arrive incomplete, unlabelled and out of order.

Agent layer

Classifies each document, extracts the data points, and lists exactly what is still missing.

02

Underwriting

Conditions accumulate; clearing them is a chase across email and portals.

Agent layer

Works the condition list, requesting, receiving, matching, and keeps the file’s status current in Encompass.

03

Closing

Dates, documents and third parties converge, or fail to.

Agent layer

Tracks every dependency against the closing date and escalates the ones that threaten it.

04

Servicing

Payments, escrow, hardship requests and complaints run for years.

Agent layer

Routes servicing requests with regulatory clocks attached, so nothing ages past its deadline unseen.

The pipeline every lender runs: application, underwriting, closing, servicing. Agents move the paper and chase the exceptions; credit decisions stay with the people and models your governance framework already covers.

Platforms and systems

Technology we work with in financial services

The systems of record this sector runs on, and why each one matters to a deployment.

Encompass
Mortgage origination of record in much of the market. The document and milestone model is what any automation has to respect.
Salesforce
Relationship and pipeline layer. Usually where the client-facing view lives even when the processing happens elsewhere.
nCino
Commercial origination on the Salesforce platform, which changes the integration approach relative to a standalone system.
Temenos
Core banking. Read-only integration is the normal starting position and often the only one that gets approved.
Snowflake
Where reporting data is increasingly consolidated, which makes it the right place to enforce a single set of definitions.

The constraint

What makes this sector harder

An examiner will ask how a decision was reached. That makes explainability a design requirement rather than a feature: every automated step needs a record a human can follow afterwards, and the steps where a model should only advise rather than decide have to be identified before the build, not after the finding.

Explainability here has a specific meaning, and it is not the technical sense. What an examiner wants is a coherent account: what information was used, what rule or judgement was applied, who was accountable, and where the evidence sits. A system that produces good outcomes it cannot account for is a finding regardless of the outcomes.

That constraint decides the division of labour. Extraction, validation, cross-checking, routing and assembly are mechanical and improve under automation. Adjudication, adverse decisions and anything with a fair-lending or disparate-impact dimension stay with a person, with the machine narrowing what they have to read rather than proposing what they should conclude.

Model risk management applies where a model influences a decision, and it is easier to satisfy when that influence is narrow and documented than when a general-purpose system has been inserted into the middle of a process. Practically this pushes the design toward many small, auditable, single-purpose steps rather than one capable agent, a shape that is less impressive in a demonstration and considerably more approvable.

The audit trail is not a report to be produced later; it has to be a by-product of doing the work. The most common expensive mistake in this sector is a deployment that improves throughput and leaves the evidence assembly manual, which converts a cycle-time gain into an examination cost.

And change control is stricter than most technology teams expect. A change to a production process that affects a control needs the same governance as any other, which means release cadence is a business conversation rather than an engineering preference.

Illuminated office towers seen from street level at dusk.

Compliance

Compliance that shapes financial services deployments

The regimes your organisation operates under, and what each one constrains in a deployment. We design to these from the first architecture diagram, they describe your obligations rather than our credentials, and VSI's own position publishes only once it is substantiated.

Model risk governance
Where a model influences a decision it needs documentation, validation and monitoring. Narrow single-purpose steps are far easier to govern than one general-purpose agent.
Fair lending and disparate impact
Any step that could affect who gets credit and on what terms stays with a person, and the basis has to be inspectable.
Records and audit trail obligations
The evidence that a control operated has to be a by-product of the work, not a report assembled before an examination.
Consumer complaint handling
Anything that is a complaint has a defined route and often a clock. Classification must fail toward escalation rather than toward a confident wrong category.

How we work with public-sector and regulated buyers

The first month

What starting looks like

What actually happens, week by week. Note where the design conversations sit, before the build, not after it.

  1. 01Week 1

    Cycle-time decomposition from your own data: how much is processing, how much is waiting, and where

    Cycle-time decomposition from your own data: how much is processing, how much is waiting, and where. This usually reframes the conversation on its own.

  2. 02Week 2

    The control map, which steps are mechanical, which are judgement, and which carry regulatory weight

    The control map, which steps are mechanical, which are judgement, and which carry regulatory weight. Second line and compliance in the room, not consulted afterwards.

  3. 03Weeks 3-4

    One mechanical step built with its audit trail as a by-product, usually completeness checking or extraction with source traceability, running in parallel with the current process rather than replacing it

    One mechanical step built with its audit trail as a by-product, usually completeness checking or extraction with source traceability, running in parallel with the current process rather than replacing it.

  4. 04End of month

    Parallel-run comparison, including how the evidence would look to an examiner, and a decision on whether to cut over

    Parallel-run comparison, including how the evidence would look to an examiner, and a decision on whether to cut over.

Next step

A free 20-minute financial services assessment

Document processing, origination workflow and controls that survive an audit.

No preparation required and nothing to install. Bring the workflow that costs you the most hours; leave with a view of what we would automate first, what it depends on, and what we would not touch.

Book the free assessment

Questions

Asked often enough to answer here

Will a model be making lending decisions?
No. Extraction, validation, cross-checking, routing and assembly are automated; adjudication stays with a person. Any step touching who gets credit and on what terms remains a human decision with an inspectable basis. This is not caution for its own sake, a design that blurs it is one you will spend the next examination defending.
How do you satisfy an examiner on explainability?
By making the trail a by-product of the work rather than a report assembled afterwards. For every automated step: what information was used, what rule was applied, what it produced, and who was accountable, recorded as it happens and exportable. The design bias toward many small single-purpose steps rather than one general agent is driven by exactly this: a narrow step is one you can account for.
What is the realistic cycle-time improvement?
We will not give you a number before measuring yours, and any supplier who does is quoting somebody else’s operation. What we can say is where it comes from: elapsed time in origination is dominated by waiting rather than processing, so the gains come from removing round-trips, asking for everything missing once instead of three times, routing exceptions by rule rather than by asking. Week one measures your own decomposition, and that is the number the business case uses.
Can this run alongside our existing process?
That is how it should start. Parallel running lets you compare outputs and evidence quality against the current process on real files, without risk, and it gives compliance something concrete to assess rather than a description. Cutover happens when the comparison supports it, not on a date agreed in advance.
How do you handle change control?
On your cadence, through your process. A change affecting a control gets the same governance as any other change to that control, which means release timing is a business decision rather than an engineering preference. Suppliers who find this frustrating tend to be the ones who have not worked in the sector.
What about the data that cannot leave our environment?
Then it does not, and the design works within that. As in healthcare, the interesting engineering here is minimisation, establishing how little needs to move for the task to work, which is usually far less than the obvious design assumes. Where processing must happen outside, it is named, agreed and approved as a decision rather than inherited as an architecture.