CASE STUDY · FINANCIAL SERVICES · APP DEVELOPMENT
A Cash Processing System Catches Risk Errors Before They Happen at an Investment Management Firm
SharePoint and Nintex workflows run risk checks inside the process itself instead of after the fact.
The Enterprise Challenge
Four distinct transaction types moved through cash processing without a system built for them.
The client is an independent investment management and strategic advisory firm, running active public equity and fixed income strategies for individuals, families, nonprofits, institutions, and financial intermediaries worldwide. Its business rests on reliability and trust, which in practice means the client data it manages and the transactions it processes have to be handled accurately every time. Cash processing sits at the center of that commitment, and it was the part of the operation the firm most needed to put on a system rather than on people remembering the steps.
The firm needed an efficient cash processing system to manage client portfolios and transactions, and it could not build one in-house. Two gaps stopped it. There was no dedicated software development methodology, and there was no in-house expertise in building or integrating advanced business processes. The complexity of the work compounded both, because this was not one process but four distinct transaction types, each following its own path, each touching the platforms the firm already ran for daily portfolio and client relationship management. Putting the processes and workflows that handle critical client data onto a system required external support.
The Solution
At a Glance
An investment management firm moved four distinct transaction types through cash processing with no system built to catch errors until after the fact. i3solutions automated the workflow on SharePoint and Nintex so risk checks now run inside the process itself.
Four distinct transaction types once handled without a system built for them now run through automated workflows on SharePoint and Nintex, one per transaction type, significantly reducing manual effort and processing time across all four, and transaction risk that was once assessed outside the process is now assessed in real time through RedOwl and returned directly into the workflow.
Strategic Trigger
Cash Processing Was the Process the Firm Could Least Afford to Leave Manual
An investment management firm’s relationship with its clients is built on reliability and trust, and cash processing is where that commitment is tested transaction by transaction. The firm’s clients span individuals, families, nonprofits, institutions, and financial intermediaries worldwide, so one set of processes carries very different account relationships. Managing critical client data through processes and workflows that had never been standardized put the firm’s most sensitive operation on its least structured footing.
The scope of the problem was not one workflow but four. Each transaction type followed its own unique process, and each needed the same accuracy as the others. Handling that variation by hand means the cash team carries the process in its own working knowledge, which is exactly the arrangement a firm cannot leave in place when reliability is the product. The firm decided to build a system for it and, lacking both the methodology and the integration expertise, to bring in a partner to do it.
Conditions That Triggered the Engagement
- Four distinct transaction types, each following its own process, handled without a system built for the differences between them
- No dedicated software development methodology in place for SharePoint or custom application work
- No in-house expertise in building or integrating advanced business processes across the platforms the firm already ran
Automating Cash Processing Without Disturbing What Already Runs
This firm automated four transaction types without touching the platforms already managing its portfolio and client relationships. If integration risk is what’s holding back a similar automation in your environment, that risk is usually smaller than assumed.
Stakes
Manual Cash Processing Costs Both Time and Certainty
Left as it was, the cost landed in two places at once. The cash team spent its hours on manual effort and processing time across all four transaction types, which is time not spent on higher-value work. And the exposure sat where transactions crossed between the systems the firm already ran, because nothing evaluated risk as part of the process itself.
The second cost was structural. Without a software development methodology, every future SharePoint or custom application project would start from scratch and produce a different result. A cash processing system built without one would have been a single fix rather than a standard, and the next system the firm needed would have met the same gap over again.
Constraints and Complexity
Four Processes, Three Platforms, and No Standard to Build On
The system had to handle four distinct transaction types, each with its own process, inside one application. It could not stand apart from the firm’s operations either. Galileo and APX are the two systems the firm runs for daily portfolio and client relationship management, and both had to stay in place while the new system worked with them. RedOwl, the firm’s external security analytics platform, added a third integration point, and the requirement there was not a report after the fact but a risk level available while the transaction is being processed.
The second constraint was procedural. The firm had no software development methodology to run the project against, so the engagement had to supply one and make it durable enough for the firm’s later SharePoint and custom application work. That set the scope wider than a single application: document the internal processes first, agree what was being automated before automating it, and leave behind a way of working as well as a system.
Selection Rationale
Senior Microsoft Specialists with Proven Delivery Depth
The requirement list named the partner profile. The firm needed a team that could design workflow automation on SharePoint and Nintex for four separate transaction processes, integrate the result with Galileo, APX, and RedOwl, and introduce a software development methodology the firm’s own people would keep using afterward. That combines process design, platform engineering, and integration work, and the firm had none of the three in-house to supervise a partner who only covered part of it.
The firm engaged i3solutions, a Microsoft Partner with 30 years of delivery experience and 1,500+ Microsoft engagements, delivered by an all-senior, all US-based delivery team. That profile matched work where defining the process and building it are the same engagement: senior engineers who could sit with the cash team to map how transactions actually move, then build the workflows and the integrations that carry them.
The Engagement Approach
i3solutions designed and implemented a custom Cash Processing System for the firm’s own business processes and workflows, built to handle four distinct transaction types, each following its own process, and integrated with the platforms the firm already ran.
PHASE 01
Methodology and Process Documentation
The firm had no software development methodology, so i3solutions introduced one and ran the engagement on it. Work started with detailed assessment, planning, and visualization: i3solutions worked with the firm’s cash team to document its internal processes, then produced process maps and wireframe diagrams capturing the systems and workflows to be automated. Those visual standards set the roadmap for implementation, and the methodology is now used across all of the firm’s SharePoint and custom application development projects.
PHASE 02
Workflow Development on SharePoint and Nintex
From the documented processes, i3solutions developed the workflow solutions that automate the firm’s cash processing, built on SharePoint and Nintex. Each of the four transaction types kept its own process rather than being forced into a shared one, so the differences between them live in the system.
PHASE 03
Platform Integration
The Cash Processing System was integrated with Galileo and APX, the two platforms central to the firm’s daily portfolio and client relationship management, so the new application works with the firm’s existing operations rather than beside them.
PHASE 04
Risk Assessment Integration
RedOwl, the firm’s external security analytics platform, was built into the application’s architecture. The system sends transaction data to RedOwl for real-time risk assessment and retrieves the risk level RedOwl returns, so the cash team can weigh it while processing the transaction.
Technical Transformation
The Cash Processing System is a workflow application with integration on three sides. SharePoint and Nintex carry the process logic: four distinct transaction types, each modeled as its own workflow rather than as variations on one, so the differences between them sit in the system instead of in the cash team’s working knowledge. Integration with Galileo and APX connects the application to the two platforms the firm runs for daily portfolio and client relationship management, so cash processing works against the same portfolio and client record the rest of the firm uses. The risk path runs outward and back: the application sends transaction data to RedOwl, the firm’s external security analytics platform, for real-time risk assessment, then retrieves the risk level RedOwl returns and puts it in front of the cash team while the transaction is still being processed. That is the architectural point of the build. The risk assessment is not a separate review in a separate tool but a value the processing workflow fetches and shows at the moment it is useful.
Measurable Outcomes
Risk Assessed Inside the Workflow
Automated SharePoint and Nintex workflows now handle all four transaction types, with real-time risk assessment built into each one.
| Outcome | Before | After |
|---|---|---|
| Cash processing workflows | Four distinct transaction types handled without a system built for them | Automated workflows on SharePoint and Nintex, one per transaction type |
| Manual effort and processing time | Manual effort and processing time on every transaction type | Significantly reduced for all four transaction types |
| Transaction risk | Assessed outside the process | Real-time risk assessment through RedOwl, returned into the workflow |
| Portfolio and client platforms | No cash processing system connected to Galileo and APX | Integrated with Galileo and APX for consistency and accuracy across platforms |
| Cash team focus | Manual effort on routine transaction handling | Time available for higher-value tasks |
| Development methodology | No dedicated software development methodology | A standard approach now used across all SharePoint and custom application development projects |
The firm published no figures for this engagement, and none are asserted here. What is recorded is the change in kind. The Cash Processing System automated complex workflows and significantly reduced manual effort and processing times for all four transaction types, which gives the cash team room for higher-value tasks. Risk moved inside the process: integration with RedOwl enables real-time risk assessment on transactions, so exposure is evaluated during processing rather than after it, and transactions are processed securely and accurately. Integration across Galileo, APX, and RedOwl holds consistency and accuracy across platforms, which is what lets the firm manage portfolios and client relationships from one operational record while its security controls stay in force.
The second result outlasts the application. Automating the workflows and centralizing cash processing reduces administrative costs and minimizes errors, and it gives the firm a reliable platform for managing critical financial operations, which enhances client satisfaction and reinforces trust. Alongside it, the software development methodology i3solutions introduced is now used across all of the firm’s SharePoint and custom application development projects, so the firm has a standard approach to build its next system against, and one that adapts as its requirements change.
Who This Engagement Serves
This engagement is relevant for
- An investment management or advisory firm processing several distinct transaction types, each with its own process, without a system built for the differences between them
- A firm whose portfolio and client relationship platforms must stay in place while a new process application works with them
- An organization that wants a risk or analytics check evaluated inside the transaction workflow rather than as a separate review afterward
Less relevant for
- Your cash processing already runs on one standard process that a packaged product covers without integration work
- You are looking to replace your portfolio or client relationship management platforms rather than integrate a new system with them
What This Engagement Established
Four Transaction Processes on One System, with the Risk Check Inside the Workflow
The engagement established that a firm can automate cash processing without disturbing the platforms it already runs on. Four distinct transaction types, each with its own process, were built as workflows on SharePoint and Nintex, and the resulting Cash Processing System was integrated with Galileo and APX, the platforms behind daily portfolio and client relationship management.
Transaction data goes out to RedOwl for real-time risk assessment and the risk level comes back into the workflow, so the cash team weighs it while processing rather than in a separate step. The engagement also left the firm a software development methodology it now applies across all of its SharePoint and custom application development projects, so the next build starts from a standard rather than from nothing.
Frequently Asked Questions
A custom cash processing system is a workflow application built around how a specific firm actually processes client transactions, rather than around a product’s assumed process. For this independent investment management and strategic advisory firm, i3solutions built one that handles four distinct transaction types, each following its own process, with the workflows built on SharePoint and Nintex. Two things separate it from a generic workflow tool. First, integration: the system works with Galileo and APX, the platforms the firm runs for daily portfolio and client relationship management, so cash processing draws on the firm’s operational record instead of holding a copy of it. Second, risk: the application exchanges transaction data with RedOwl, the firm’s external security analytics platform, so a risk assessment is available inside the process rather than beside it.
A custom Cash Processing System for managing client portfolios and transactions. It handles four distinct transaction types, each following its own process, with the workflows built on SharePoint and Nintex. It draws on Galileo and APX for portfolio and client relationship management, and it exchanges transaction data with RedOwl for risk assessment. The build started with detailed assessment, planning, and visualization: i3solutions worked with the firm’s cash team to document the internal processes and produced process maps and wireframe diagrams covering the systems and workflows to be automated, so what was being automated was agreed before it was built. Alongside the application, i3solutions introduced a software development methodology, which the firm now uses across all of its SharePoint and custom application development projects.
No. Galileo and APX stayed in place as the firm’s daily portfolio and client relationship management platforms, and RedOwl stayed as its external security analytics platform. The new Cash Processing System was integrated with all three rather than replacing any of them. That is the usual shape of this work in an investment management setting, because the portfolio and client relationship platforms are the system of record for the business and moving off them is rarely the problem the firm set out to solve. The integration work is what makes the arrangement hold. The new application has to work against those platforms accurately enough that the cash team can trust one screen, which is why platform integration was scoped as its own part of the engagement rather than treated as a connector detail.
It is checked in real time as part of the workflow. The application sends transaction data to RedOwl, RedOwl determines the risk level, and the application retrieves that result, so the cash team sees the risk assessment in the same system it uses to process the transaction. The sequencing is the point. The risk level arrives while the transaction is being processed and can be weighed then, rather than surfacing in a separate security review afterward. RedOwl remains the firm’s external security analytics platform and keeps doing that job. The Cash Processing System does not reimplement risk scoring, it asks for it and shows the answer where the decision is being made, which turns risk assessment from a parallel activity into a step inside the process.
That was the starting position here. i3solutions introduced a development methodology as part of the engagement, and the firm now applies it across all of its SharePoint and custom application development projects. The work also began with documented process maps and wireframe diagrams built with the client’s cash team, so the workflows were mapped before they were automated. A missing methodology usually shows up later rather than sooner: the first system gets built somehow, the second one gets built differently, and nothing carries between them. Supplying the methodology alongside the application is what makes the engagement a standard the firm keeps rather than a one-time delivery, which is why it is described here as a result of the project and not only as how the project ran.
By documenting the processes before automating them. On this engagement the work began with detailed assessment, planning, and visualization: i3solutions collaborated closely with the firm’s cash team to document its internal processes, then built process maps and wireframe diagrams capturing the systems and workflows to be automated. Those visual standards gave the implementation a roadmap and kept the new system aligned with existing operational needs. Development followed, with workflow solutions on SharePoint and Nintex, and then the integration work connecting the application to Galileo, APX, and RedOwl. The order matters in a cash context, where four transaction types each carry their own process and the differences between them are the substance of the requirement rather than an edge case to be normalized away.
i3solutions is a Microsoft Partner with 30 years of delivery experience and 1,500+ Microsoft engagements, with every engagement staffed by an all-senior, all US-based delivery team. This engagement shows why that profile matters for financial process work. The firm had neither a software development methodology nor in-house expertise in building and integrating advanced business processes, so the partner had to supply the process discipline as well as the build. The work spanned process documentation with the cash team, workflow development on SharePoint and Nintex for four distinct transaction types, and integration with Galileo, APX, and RedOwl, including a real-time risk exchange inside the workflow. For firms weighing similar work, a short scoping conversation establishes what the equivalent build would take in your environment.
Related Insights
More From i3solutions
Related Engagements
Risk Assessed Inside the Workflow, Not After It
Real-time risk assessment now runs inside the transaction workflow itself, rather than as a separate downstream step. We can talk through what a comparable risk-integrated workflow would look like for your firm.
