A bank can outgrow its software long before it outgrows its building. In its 2011 annual report, the Infrastructure Development Bank of Zimbabwe described buying Neptune’s Rubikon core banking system for $850,000. The reason was refreshingly specific: its previous Leasepac system struggled with loan transactions and web-based products. Another $265,019 went on hardware upgrades. Together, those disclosed items came to $1,115,019.
That old bill offers a useful introduction to Neptune Software Group. This company sells the systems financial institutions use to run their business: recording accounts, administering loans, moving transactions through approvals and connecting banking channels. Its customers have to make those functions work together. A new feature is only useful if the rest of the bank can keep up.
Neptune’s flagship is Rubikon, a universal banking platform. Orbit-R serves microfinance institutions and savings cooperatives. Across both, the commercial proposition is practical: give an institution room to change its products and operations without replacing its entire technology foundation every time.
The old system ran out of room
IDBZ’s explanation gives the story its clearest cause and effect. The bank’s requirements had moved beyond what its previous system could comfortably support. Its report called out “serious limitations in handling loan transactions and web based products.” That is a functional mismatch, rather than evidence of a dramatic outage. The replacement addressed the bank’s capacity to do business.
The distinction matters for anyone buying enterprise software. A system can remain operational while making the next business decision difficult. A lending organization may need to change how it schedules payments, introduce a new channel or handle a more complicated product. Eventually, accommodating the next requirement becomes the purchasing argument.
Malawi Savings Bank offered another version of that story in 2009. Its managing director said the business environment had changed since the acquisition of its Bankplus system. The bank wanted internet and mobile banking, business intelligence and customer relationship functions. It selected Rubikon after a process lasting more than 12 months.
The revealing detail was the selection criterion. Sam Phiri, the bank’s head of information technology, emphasized the “ability to deliver and provision of post implementation support.” Neptune’s experience in neighboring countries helped its case. The bank was choosing people who would remain useful after the contract ceremony.
“ability to deliver and provision of post implementation support”
Sam Phiri · Malawi Savings Bank · 2009
A banking product is a bundle of rules
Rubikon’s published lending functions follow a loan through its working life: application, setup, disbursement, repayment scheduling, rescheduling and delinquency management. Collateral, group lending and customer limits also feature. This is the part of banking software where the ordinary exceptions accumulate. Someone pays late. Someone needs different terms. Someone must authorize the change.
Neptune places configurable business rules and integrated workflow at the center of its product description. It says banks can change operating rules without returning to the vendor for every adjustment. The appeal is straightforward: business staff need some control over the procedures they administer.
The wider suite reaches into retail banking, customer information, electronic channels and treasury. Its digital banking offering includes ATM/POS, internet, mobile and SMS access. Treasury covers activities such as foreign exchange and money-market trades, taking them through settlement and accounting. Rubikon also supports multiple currencies and languages.
Those capabilities put Neptune in the enterprise core banking market, where the purchase affects operations across an institution. Its expertise sits in the connection between banking processes and software configuration. The person evaluating a demonstration should therefore bring the bank’s awkward cases: revised repayment schedules, approval exceptions and the reports staff actually need at closing time.
and fees
and approvals
and audit trails
Fifteen minutes, carefully defined
Orbit-R brings the same modular approach to microfinance. The company describes a system institutions can expand by enabling further capabilities over time. That matters in a market where a lender’s product range and organizational complexity can change substantially as it grows.
A concrete example arrived in April 2024, when Neptune announced Orbit-R live at Kenya’s Solution SACCO. The announcement highlighted role-based sign-on, adjustable rates and fees, audit trails and layered approvals. It also said new branches and products could be configured in as little as 15 minutes without technical staff assistance.
Read that claim with the noun attached. It concerns configuration, not the migration of an entire financial institution. Moving customer records, checking balances and preparing employees is a different task. A useful demonstration would ask a prospective user to configure a realistic savings or loan product and show how another employee reviews the result.
The cooperative setting also sharpens the question of who benefits. Solution SACCO’s membership spans several employment and community groups. The software has to support staff administering member-focused savings and credit. Its value depends on whether the procedures are workable for those staff, day after day, across the institution’s actual products.
The support organization is part of the product
Neptune’s UK company was incorporated on June 22, 1999. Founder Simeon Chijioke Agu was a figure in Nigeria’s software industry; contemporary tributes identified him as the first president of the Institute of Software Practitioners of Nigeria. His history gives the group roots that extend beyond the London address on its corporate registration.
Today, the official leadership page identifies Chuka Agu as chief executive and dates his appointment to 2013. It describes a delivery organization with regional banking experience: East Africa director George Ochieng previously worked in banking finance and operations, while West Africa director Adeniyi Badejo’s background combines banking and technology sales.
Product engineering has a substantial Chennai presence. Thomas Waltair, the India regional director, joined in 2006 as the first member of that office, according to his biography. The company describes his engineering team as numbering more than 100. The arrangement pairs software development in India with customer-facing regional expertise.
The company’s own cultural signals are modestly revealing. Its staff page includes a cricket gathering; its inclusion statement emphasizes different backgrounds and perspectives. More consequential for customers is its declared emphasis on personal responsibility in business relationships. A bank can test that promise by meeting the people who will handle its implementation and continuing support.
A license starts a working relationship
The Malawi contract explicitly licensed Rubikon’s use. Alongside its software, Neptune offers consulting, implementation and training. This is an enterprise sales and delivery business: the scope of the institution’s requirements helps determine the work around the product.
Its services description includes formal project methods, configuration guidance and different training formats. Banks can choose onsite or offshore instruction and train-the-trainer programs. The published materials include process documentation, facilitator guides and training data. These are unglamorous details with practical consequences. Staff need to rehearse the work they will do when the system becomes operational.
Neptune’s early Rubikon history shows why delivery references matter. An April 2009 announcement described Zimbabwe’s TN Bank as its first live bank-wide deployment. It covered several banking functions, including treasury and electronic banking. For a new platform, a functioning customer installation gives prospective buyers something more substantial to examine than a feature list.
Competition has included familiar core banking suppliers. Historical industry reporting described Rubikon winning Victoria Commercial Bank against offerings from Infosys, Temenos and I-flex. That record establishes the sort of purchasing contest Neptune entered. It does not settle a present-day comparison: the buyer still needs to test current functionality, implementation capacity and support for its own market.
The next geography, the next interface
The newsletter available through Neptune’s website in 2026 outlines recruitment of partners in Eastern Europe and Central Asia, with the Caucasus also among its target regions. The company is seeking system integrators and technology collaborators. It is an expansion agenda, not evidence that every named market already contains a deployment.
The same publication introduces Nova Core AI, describing a banking assistant with natural-language queries, document search and role-based information access. Analytics and Islamic banking capabilities also feature. These additions suggest an effort to sell more functionality around the core banking relationship.
Its account of Berhan Bank provides a longer view: the newsletter describes 17 years of collaboration and a third major Rubikon upgrade. That relationship suggests the opportunity in serving a customer through successive changes. The practical challenge is to make new capabilities useful within an institution that already has established data, staff and procedures.
Bring the difficult transaction to the demo
The lesson a buyer can copy is to begin with a documented constraint. IDBZ identified the work its old system could not adequately support. Malawi Savings Bank examined delivery and continuing support. Both are better starting points for evaluation than an undifferentiated wish list.
Then make the proposed solution demonstrate that work. Ask how a revised loan is approved, how its history can be inspected and who can alter the underlying rules. Put the staff who perform those tasks in the room. Price the implementation environment alongside the software, and distinguish a quick configuration exercise from the preparation required for a full migration.
That approach also exposes the conditions under which a purchase disappoints. Configurability helps little if nobody owns the operating rules. A broad suite can be an expensive fit for an institution with narrow requirements. Regional experience only helps a new market when the delivery team understands local needs. Neptune’s case is strongest where its banking functions and implementation experience meet a clearly defined operational problem. That is the problem to bring to the first meeting.