Time and time again, Saccos have found themselves with the wrong choice of core banking system. What should be a strategic investment that enables growth, efficiency, flexibility, and better member service can instead become a costly and frustrating experience.
In some cases, the problem starts long before a vendor is selected. It begins with the procurement process itself.
- Allowing the Consultant to Become the Originator of the Requirements
One of the biggest mistakes a Sacco can make is allowing a consultant to take full control of the procurement process.
A consultant should guide the Sacco through the process, not define the Sacco’s needs on its behalf.
Before beginning procurement, the Sacco should first develop its own user requirements based on its business strategy, operational challenges, regulatory environment, growth plans, and future needs. These requirements should then form the basis of the Request for Proposal (RFP).
Unfortunately, this is not always the case. In some instances, consultants reuse RFPs prepared for other institutions. The result is a document containing requirements that may not be relevant to the Sacco in question.
This creates two problems. First, the Sacco may end up paying for functionality it does not need. Second, the inflated cost of such a system may push the Sacco toward a cheaper solution that does not adequately address its actual requirements.
- Focusing on “Good-to-Have” Features Instead of Business-Critical Requirements
Core banking systems are generally priced according to the number and complexity of modules and functionality required.
Saccos therefore need to distinguish between must-have functionality and good-to-have functionality.
Not every feature demonstrated by a vendor is necessary. The key question should be: Does this functionality solve an identified business need?
A Sacco should prioritize capabilities that directly support its strategy, operations, member experience, reporting, compliance, risk management, and growth.
Buying functionality simply because it is available can unnecessarily increase both implementation and long-term maintenance costs.
- Using Price as the Primary Evaluation Criterion
Another common mistake is opening and considering the financial proposal too early in the evaluation process.
Technical capability, functional fit, implementation methodology, vendor capacity, support, scalability, flexibility, and security should first be evaluated objectively. Commercial evaluation should then be undertaken in accordance with a clearly defined procurement methodology.
Choosing the lowest bidder does not necessarily mean choosing the lowest-cost solution.
A vendor may submit a seemingly attractive price while excluding important third-party integrations, implementation activities, customization, training, data migration, support, or other costs.
These costs often emerge later in the implementation when the Sacco has limited room to negotiate. At that point, the project may already be too advanced for the Sacco to change direction.
The real question should therefore be:
What is the total cost of ownership, not simply the initial purchase price?
- Failing to Carry Out Comprehensive Vendor Due Diligence
Selecting a core banking system is also a decision about selecting a long-term technology partner.
Saccos should therefore conduct thorough vendor due diligence before making a decision.
This should include examining:
- The vendor’s experience in the Sacco sector.
- The number and quality of successful implementations.
- The stability and maturity of the system.
- Financial and organizational stability of the vendor.
- Customer references.
- Quality of post-implementation support.
- Product development roadmap.
- Vendor staff turnover.
- Availability of skilled implementation resources.
- Experience with integrations and data migration.
- Contractual and exit arrangements.
One area that is often overlooked is vendor staff turnover.
If the team that starts an implementation leaves before the project is completed, knowledge is lost, responsibilities change, and implementation timelines can be extended. A Sacco should therefore understand the stability of the vendor’s implementation and support teams before signing a contract.
- Giving Vendors Insufficient Time During Demonstrations
Some Saccos unnecessarily limit the time allocated to system demonstrations.
A core banking system is too complex to be properly evaluated through a short presentation.
The objective of a demo should not simply be to see attractive screens. The Sacco should test whether the system can support real business processes.
Vendors should be required to demonstrate end-to-end transaction processing.
For example, rather than demonstrating a front-end screen that appears to process a transaction, the vendor should demonstrate the entire process, including the underlying posting, accounting entries, balances, reporting, and relevant downstream processes.
There is a significant difference between demonstrating a screen and demonstrating a working system.
If sufficient time is not allocated for proper evaluation, a Sacco may select a system based on functionality that appears to exist during the demonstration but requires significant development during implementation.
The consequences can include extended implementation timelines, additional costs, and disruption to the Sacco’s operations.
- Failing to Test System Flexibility
The Sacco sector operates in an environment that continues to evolve.
Products change. Regulations change. Member expectations change. Business models change.
One of the most important requirements when procuring a core banking system should therefore be flexibility.
The system should allow the Sacco to configure products and processes without having to depend on the vendor for every minor change.
A Sacco should ask:
- Can products be configured internally?
- Can parameters be changed without vendor intervention?
- Can new products be introduced quickly?
- Can workflows be modified?
- Can the system adapt to regulatory changes?
- Can the Sacco integrate new digital channels and third-party services?
- How much customization will be required for future changes?
A system that requires the vendor to make every change can become expensive and restrictive over time.
- Underestimating Reporting Requirements
Reporting is another area that is frequently overlooked during procurement.
Saccos need management reports, operational reports, regulatory reports, financial reports, audit reports, and increasingly, business intelligence and analytics.
A Sacco should understand how much control it will have over its own data and reporting after implementation.
If the Sacco cannot create or modify reports without vendor intervention, even relatively simple reporting requirements can become expensive and time-consuming.
The ability for authorized Sacco staff to create, modify, and extract reports should therefore be evaluated as part of the core banking system selection process.
- Ignoring Implementation Realities
Core banking implementation is not a simple IT project. It affects virtually every part of the organization.
Depending on the scope, complexity, integrations, data migration requirements, and organizational readiness, implementation can take a considerable amount of time.
Saccos should therefore be cautious when vendors provide overly optimistic implementation timelines.
The Sacco should understand exactly what is included in the implementation plan, who is responsible for each activity, what resources are required from the Sacco, what assumptions have been made, and what constitutes successful completion.
A vendor should not be allowed to leave the implementation site while significant functionality remains incomplete.
A clearly defined acceptance process, implementation milestones, deliverables, and post-implementation support arrangements are essential.
- Allowing Personal Interests to Override Institutional Interests
Perhaps the most damaging mistake occurs when individual interests take precedence over the interests of the organization.
Technology procurement decisions should be based on transparent, objective, and documented criteria.
Where personal interests influence the selection of a system, the Sacco can end up spending years trying to implement a solution that was not the right fit from the beginning.
The consequences can extend beyond the technology project. Management attention is diverted from business growth, member service, innovation, and operational improvement.
In extreme cases, failed technology projects can contribute to the resignation or removal of senior executives, board members, or IT leadership.
The responsibility for avoiding this outcome rests with the entire institution.
- Becoming an Unwitting Entry Point for an Unproven System
There is nothing inherently wrong with adopting a relatively new system or becoming one of its early customers.
However, the Sacco must understand the risks.
A new system may offer innovative functionality, but the institution should establish whether the underlying technology is sufficiently mature and stable for its operational requirements.
The Sacco should conduct adequate reference checks and establish whether the vendor has successfully implemented the system in environments comparable to its own.
Innovation should be encouraged—but not at the expense of operational stability.
- Signing Contracts Without Adequate Exit Protection
A core banking contract can potentially bind a Sacco to a vendor for many years.
Saccos should therefore pay close attention to contractual provisions relating to termination, support, licensing, upgrades, data ownership, data portability, integrations, service levels, warranties, and exit arrangements.
A contract that makes it prohibitively expensive for a Sacco to exit an underperforming relationship can leave the institution effectively locked into a system that no longer meets its needs.
The Sacco should negotiate not only for implementation success but also for protection in the event that the relationship does not work as expected.
What Should Saccos Do Differently?
Before procuring a core banking system, Saccos should consider the following principles:
Be the originator of the requirements.
The Sacco understands its business better than the consultant or vendor. Consultants should guide the process, not define the business requirements.
Remain actively involved in procurement.
The board, management, business users, IT team, finance team, operations team, and other relevant stakeholders should participate throughout the process.
Conduct comprehensive vendor due diligence.
Do not evaluate only the software. Evaluate the company, implementation team, support structure, customer references, staff turnover, financial stability, and product roadmap.
Focus on must-have functionality.
Prioritize functionality that addresses actual business requirements instead of accumulating expensive features that may never be used.
Evaluate total cost of ownership.
Look beyond the initial quotation and examine implementation, integrations, customization, licensing, support, upgrades, training, infrastructure, and future costs.
Give vendors adequate time for demonstrations.
Test real business processes and insist on end-to-end transaction demonstrations rather than presentations of attractive screens.
Prioritize flexibility.
The system should allow the Sacco to configure products, workflows, reports, and processes as its business evolves.
Negotiate with the best-evaluated vendor—not necessarily the cheapest vendor.
Once the best-fit vendor has been identified, negotiate aggressively on price and commercial terms. Do not compromise the institution’s long-term interests simply to obtain the lowest initial price.
A core banking system should be viewed as a strategic business investment rather than simply an IT purchase.
The wrong system can lock a Sacco into expensive maintenance, prolonged implementations, vendor dependency, operational disruption, and lost growth opportunities. The right system, on the other hand, can provide the flexibility, efficiency, reporting capability, and scalability required to compete and grow.
The most important lesson is:
Saccos should not procure core banking systems merely by asking, “Which system is cheapest?” They should ask, “Which system best fits our business today, gives us the flexibility to grow tomorrow, and provides sustainable value over its entire lifecycle?”
That is the question that should drive the procurement process.
Ewin Kinyua is a strategic leader with extensive experience in business development, organizational growth, and financial services. As Senior Business Development Manager at Neptune Software Group, he drives partnerships and helps financial institutions across Africa adopt innovative core banking solutions.
