Treasury Software Vendors: Project-Oriented vs. Product-Oriented


When evaluating Front to Back Treasury System (and Vendor), CIOs from Financial and Corporate Institutions (FCI) get involved into sophisticated selection processes, many of them driven by world-class consulting companies, including vendor selections, RFC (Request for Information) & RFP (Request for Proposal), proof of concepts, workshops, etc. Finally, FCI “decision-makers” tip the scale for a local, regional or world-class vendor.

However, are FCIs licensing a product or a project? How much is it really going to cost (time and money) to be up-to-market on top of the selected product in a long-term strategy?

In the whole selection process, the IT and Business areas have to understand clearly how the hired works internally in terms of product evolution. Are the FCI going to benefit from other clients’ requests, innovations and regulatory requests or will they just need to pay an army of consultants for any new need that arises? That is, basically, are you hiring a Project-Oriented or a Product-Oriented vendor? This article highlights a number of considerations to be taken into account when evaluating vendors and deciding which the internal FCI long-term strategy is.

Evaluation Process (RFI/RFP): What makes a vendor attractive

FCIs identify a set of criterion when qualifying a vendor accordingly with their needs, concerns and internal processes. The following list could be potentially considered as a list of well-known issues to be taken into account:

  • Coefficient of functional support
  • Costs:
  1. Structure and Cost of Licenses (up-front payments plus annual maintenance versus monthly renting fee)
  2. Implementation services fees
  3. Maintenance fees under SLA (Service Level Agreement)
  • Technology platform (open architecture, database, service-oriented architecture (SOA), modular components, cloud, warehouse, customisation and parameterisation, etc)
  • Ability to execute: time to deliver and implement
  • Local or Regional offices
  • Number of local installations
  • Presence in similar clients
  • Regulatory support
  • Help Desk and Post-Production Service Support
  • Vendor’s Clients references
  • Vendor’s reputation
  • Vendor financial strength
  • Standard Processes (e.g. Capability Maturity Model Integration (CMM-I), ISO)
  • Release Scheme for both Major Releases and Minor Patches

All issues mentioned above are weighted indistinctively as per FCIs requirements, qualifying vendors conveniently.

Product-Oriented versus Project-Oriented

This section is assuming that the IT and Business areas of FCI would be more interested in Product-Oriented vendors instead of Project-Oriented ones. Then, a number of considerations must be taken into account when evaluating the vendors’ benefits. The IT area must develop a mechanism at early stages (RFI/RFP) for drilling down what the vendor is saying in terms of Maintenance and Major-Release practices versus what the vendor is actually doing.

The following chart summarises a set of matters to bear in mind during RFI/RFP processes as open questions for vendors. It is not suggesting which the appropriate answer is, it is just meant to highlighting what decision markers and technical recommenders must evaluate from vendors, in line with the FCI strategy.


Subject Vendor in depth Goal
Maintenance and Release Practices
  • Which is the vendor practice for the release of new versions?
  • Is there a planned and established schedule for the whole year?
  • Is there any distinction between Major Releases and Minor Patches? Which is the vendor’s standard annual frequency?
  • How are new regulatory demands supported in terms of releases?
  • Are resources from Vendor or Consulting Partners usually available for FI?
Measure Time-To-System
Product Evolution
  • Are you getting other clients’ functionality enhancements under the release practices?
  • Are you charged for that? Is that part of the product-line evolution of the product? Is this part of the major releases?
  • Does the vendor maintain branches per client for product evolution or just a major common version?
Measure level of Product-Oriented practice
Quality Control in Release Practices
  • Are UAT (User Acceptance Test) vendor resources for new versions included in SLA? How many releases will be delivered per year?
  • Is the vendor under a CMM-I or ISO quality assurance program?
  • Is your vendor running regression tests for Maintenance and Major-Releases? Do you know if the vendor’s test cases include your main business use cases? Does your vendor provide consistent evidence of such testing?
  • Do I need budgeting for internal UAT processes?
  • Is there any mandatory upgrade to be applied to every established frequency?
Measure Quality Process and FCI Cost when upgrading
R&D+i (Research and Development plus Innovation)
  • Is your vendor running an R&D+I department?
  • Is this focused on technology, financial business or both?
  • Is this part of the Release-Practices program?
  • Do you need to pay for that?
  • Can you participate in the program?
  • Is there a plan for annual deliveries?
  • Is there a User’s Club?


Measure Functional Evolution of the Product
Pricing Structure
  • Do you need to pay new licenses schemes when upgrading to a major release?
  • Are you charged for any maintenance (minor) release?
  • Is the SLA covering a number of hours for minor enhancements?
  • Which are the considerations for your budget when you wish to incorporate new product-line functionality available in recent versions?
Measure Pricing Scheme for new requirements and market needs
  • Distinguish among vendors with:
  1. Local presence, either as a native or as a foreign company, specialised only in the local environment.
  2. Regional, usually benefits from a centralised way of driving their business, reusing processes and components for several countries in the region.
  3. International, world-class (sometimes) consolidated and multi-continent software serves hundreds of clients, but adaptability costing usually time and money

Understanding of local and regional concerns


Functional perspective and globalisation

All of the above are evaluation questions for vendor centers on how the product organisation is equipped to provide infrastructure mechanisms, consulting services, resources and –mainly- upgrade schemas to keep your version up-to-market at an appropriate (minimum) cost.

For the consistent attainment of business goals related to any financial software, IT areas must pay special attention on how vendors’ release practices are being carried out. On the downside, the FCI ends up with an old-fashioned version of the product and spending considerable amounts of money on new licenses and consulting services just to catch-up with new financial markets’ needs and regulatory demands.

According to Gartner’s vision, all kinds of vendors must also finally be evaluated in terms of two relevant concepts: local market understanding (LMU) and geographical execution (GE). The LMU is the ability of the vendor to respond to anticipated and unanticipated local financial market requirements. This shows how closely connected the vendor is to the local financial industry. The GE focuses on the ability of the vendor to extend its own or external resources to deploy its software platform. Fundamentally, as many vendors drive to expand market presence, this criterion assesses how effectively they can leverage limited resources and then, either via partners and subsidiaries to provide the implementation consistency across the target markets.



Every FCI must balance its strategy when evaluating the vendor’s capabilities. RFI/RFP cannot merely be a process where a spreadsheet is fully filled by Vendors and Consultant companies and later contrasted only with a number of demonstrations or workshops. It needs to incorporate the FCI long-term strategy, that is: are they looking for Product-Oriented or a Project-Oriented vendor?

By Lucio Dinoto

Lucio is the Business Development Manager at Lumina Americas. In this role he explores global opportunities (mainly in LATAM, but also Spain and Portugal) and participates intensively in the execution of front office and risk management software projects in the Financial Industry. Lucio has a degree in Computer Science and a MBA in Finance and Management, both from Argentina.



Related reading