Findur is too important and often too heavily customized to support reactively. A strong Findur support model combines technical expertise, disciplined processes, effective collaboration, and a deliberate effort to reduce avoidable complexity.
Supporting Findur Is More Than Incident Resolution
Supporting a sophisticated treasury and risk management system (TRMS) such as Openlink Findur can feel more like an art than a science. Findur has a broad functional footprint, a complex architecture, and a seemingly endless number of ways in which a problem can present itself. The answer is often buried somewhere in a log file, history table, interface message, configuration setting, or custom plugin. Finding it takes time, expertise, and patience. Then selecting one of the multiple perfectly valid solutions presents its own challenge.
That complexity is unavoidable to a degree. Findur supports critical trading, treasury, settlement, accounting, and risk processes, and it usually sits at the center of a much wider technology landscape. However, support does not need to be chaotic. A well-designed Findur support model should reduce operational risk, shorten resolution times, and free experienced resources to focus on improvements rather than repeatedly solving the same problems.
Why Findur Support Is Difficult
Complex integrations
Findur commonly interfaces with enterprise resource planning systems, market data providers, trading execution platforms, confirmation services, payment and settlement networks, data warehouses, and downstream risk and reporting applications. A failure may originate in Findur, but it could just as easily begin upstream or appear only after data has moved downstream. Effective support therefore requires visibility across the full business process, not just the Findur application.
High availability and performance expectations
Findur supports time-sensitive trading and risk management activities. Downtime, delayed processing, or degraded performance can have immediate financial and operational consequences. Support teams must be able to distinguish a local user issue from a broader platform problem, identify the affected process, and act quickly without introducing further risk. Are random database disconnections, deadlocks, or proxy errors an application issue, network problems, or some mystery third thing?
Customization and configuration
Findur provides extensive configuration options and several ways to extend the platform, including JVS, OpenComponents, Report Builder, TPM, and other framework tools. These capabilities are valuable, but every customization creates a support obligation. Poorly documented, unnecessary, or overengineered custom code increases the difficulty of troubleshooting, testing, upgrading, and onboarding new support resources. Simpler is often better.
A large and specialized functional footprint
A user can work with Findur for twenty years and still discover a useful screen or function that they have never used before. I saw a screen I had never seen before just last week! New users require role-specific training, but experienced users also need continued support as business processes, products, and system capabilities change. A support model must therefore cover both technical incidents and functional questions.
Core Components of a Best-Practice Support Model
A strong Findur support model is not defined by the size of the support team. It is characterized by how the application is used, including clear ownership, quality of information, repeatable processes, and access to the right expertise when it is needed.
Onboarding, training, and knowledge retention
Training should be aligned to the user’s role and delivered before access is granted wherever practical. Users do not need to understand every part of Findur, but they should understand the workflows, controls, and exception paths relevant to their responsibilities.
- Provide role-based onboarding for new users and support personnel.
- Refresh training when workflows, controls, or system behavior change.
- Avoid concentrating critical knowledge in one or two long-serving individuals.
This can be coupled with the expert user model, where individuals from each team are nominated to be super users in a particular process or broad area of functionality. The trick is to avoid key person risk where one individual holding all knowledge becomes an operational risk.
Proactive monitoring and maintenance
The support team should not wait for a user to report every failure. Monitoring should cover application health, batch and service status, interface queues, data flows, processing volumes, and key business deadlines. Alerts must be actionable: excessive noise trains support teams to ignore the very signals they need.
- Monitor critical services, interfaces, queues, and scheduled processes.
- Track business-level outcomes, not only technical availability.
- Define ownership and escalation paths for every monitored component.
Disciplined incident management
A comprehensive incident process should define how issues are identified, prioritized, investigated, communicated, resolved, and reviewed. Tools such as Jira can provide a useful record of incidents and actions, but the tool is not the process. The quality of the information recorded matters more than the ticket count: each Jira should have clear ownership, and notes kept concise and insightful to the problem at hand. Duplicated or overlapping Jiras should be avoided.
Logging is particularly important. Standard Findur logs can generate a great deal of noise, while custom plugins often record too little context. Consistent, structured logging should make it possible to identify what failed, where it failed, which transaction or message was affected, and what the system did next. Root cause analysis should result in permanent corrective action wherever possible, rather than a larger collection of workarounds.
Effective change management
System updates, configuration changes, and custom developments should follow a controlled process that includes impact assessment, peer review, testing, approval, deployment, and rollback planning. The level of control should be proportionate to the risk, but production changes should never depend on informal knowledge or unrecorded manual steps.
- Maintain source control and a clear versioning strategy for custom code and configuration.
- Record dependencies between plugins, workflows, reports, interfaces, and static data.
- Review emergency changes after implementation and move any temporary fix into the standard process.
Apply risk-based deployment controls
Not every production change carries the same level of risk. A change to a business-critical valuation, settlement, or accounting process should follow a more rigorous route than a minor Report Builder amendment, TPM configuration change, Accounting Query, Distributed Mapping update, or simple, well-contained code change. Applying the same governance to every deployment can create delay without materially reducing risk.
A mature Findur support model should define deployment routes according to factors such as business criticality, technical complexity, reversibility, testing coverage, and the potential financial or operational impact. Lower-risk changes can use a shorter approval and testing path, provided they remain documented and capable of being rolled back or fixed forward quickly.
This approach depends on the capability of the team. A team that understands the affected process, has reliable testing and monitoring, and can diagnose and fix forward safely can accept a different level of deployment risk from a team that lacks that expertise. Risk-based governance should remove unnecessary friction, not become an excuse for uncontrolled production changes.
User support and feedback
A dedicated support function should be able to handle both technical problems and user questions. It should also identify patterns. Repeated user errors may indicate a training gap, but they may equally indicate poor workflow design, unclear controls, or unnecessary complexity.
Regular ownership reviews should be performed for reports, plugins, saved queries, templates, workflows, and other custom objects. Anything without a clear owner, current business purpose, or recent use should be challenged. Removing obsolete components reduces risk and makes the remaining estate easier to understand.
Collaboration Between Business, IT, and Specialist Partners
Business and IT must share ownership
Findur support is most effective when business and IT teams work as one service rather than passing incidents back and forth. Cross-functional teams should collaborate, not work in conflict against each other. Regular service reviews should cover system performance, upcoming changes, recurring incidents, control weaknesses, and improvement priorities.
The business should also help define and maintain test cases for regression testing, upgrades, and new functionality. Technical teams can confirm that the system executed a process; business users are better placed to confirm that the result is operationally and financially correct.
Use specialist third-party support deliberately
Organizations do not need to retain every Findur skill internally. A specialist support partner can provide deep product expertise, additional capacity during critical periods, and continuity when internal resources are unavailable. The objective should be to complement the internal team, transfer knowledge, and provide access to skills that would be inefficient to maintain full time. This can be the solution to any key person risk, with consultants helping to diversify knowledge away from any one individual through training or supplementation.
Manage the software vendor without becoming dependent on it
A strong relationship with ION remains important for product fixes, technical guidance, release information, and escalation. Service levels and vendor performance should be reviewed regularly. However, the support model should not assume that every issue can or should be handed to the vendor. Organizations should retain enough internal and independent expertise to diagnose problems, challenge responses, and understand the alternatives available.
There are also areas where using the vendor is the most economical and lowest-risk option. Annual SWIFT maintenance is a good example: adopting ION-supported maintenance releases is generally more cost-effective and sustainable than maintaining a custom interpretation of evolving message standards. The same principle can apply to regulatory changes, compatibility updates, and other recurring product maintenance that the vendor is already responsible for delivering across its client base.
Good support is not about maximizing either insourcing or outsourcing. It is about making deliberate ownership decisions. The core platform should remain as close as practical to the way it was designed and supported, with customization reserved for requirements that cannot be met sensibly through standard functionality or vendor-supported extensions.
The Goal: Low-Maintenance Production Support
The end goal is not a larger support team. It is also not to outsource all support to third-party teams. The goal should be a lower-maintenance production environment. That means reducing the number of avoidable incidents, shortening the time required to diagnose those that remain, and allowing skilled resources to spend more time on strategic improvements.
Automate what can be automated
- Continuously monitor system performance, data integrity, interfaces, and critical processing.
- Generate automated health and exception reports that highlight where action is required.
- Automate toil, repetitive operational checks and recovery steps. where the risk is understood.
- Invest in automated regression testing to make deployments safer and reduce upgrade timelines.
Simplify the estate
Support processes should be standardized, unnecessary steps removed, and recurring manual work challenged. Where practical, organizations should return to Findur’s core functionality and retire legacy customizations that add more maintenance cost than business value. Standard vendor functionality is usually easier to patch, upgrade, document, and support than an equivalent custom solution. Customization is not inherently bad, but not all customizations are created equally. The trouble starts when they are overengineered or just plain unnecessary.
Document the system where the work happens
Documentation should cover architecture, interfaces, configuration, custom code, operational procedures, and recovery steps. It must also be maintained. A large document that nobody trusts is less useful than a short, current guide linked directly to the process it describes.
Where possible, use Findur’s own capabilities to make processes self-explanatory. Clear naming conventions, TPM visual design, workflow notes, meaningful error messages, description fields, and embedded operational guidance all reduce the distance between the system and its documentation.
Ben Jackson
Capital Markets Lead – EMEA