Automation of SACCOs - FSD Kenya
Automation of SACCOs - FSD Kenya
Automation of SACCOs - FSD Kenya
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
5. Orbit (Neptune)<br />
Fulfilment <strong>of</strong> requirements: Orbit is a derivative <strong>of</strong> Neptune’s Equinox,<br />
which has been adapted to suit <strong>SACCOs</strong>. The system is deemed sufficient, but<br />
has a few shortcomings. The teller functionality is satisfactory. Different teller<br />
types with configurable rights are provided. Rules can be applied to standing<br />
order to make certain transactions under certain conditions. To enable<br />
integration with an ATM network, the acquisition <strong>of</strong> an external module<br />
connecting the application to a switch is required. Customers are identified<br />
by a unique reference number. The assignment <strong>of</strong> customer types enables<br />
classification and respective reporting. Also products can be restricted to<br />
certain customer types. The provided search functionality is strong. However,<br />
the data model <strong>of</strong> the application is unclear with regard to the necessary<br />
synchronisation <strong>of</strong> FOSA data to the BOSA module. FOSA and BOSA data<br />
appear not to be stored on one central database and synchronisation between<br />
the two is necessary.<br />
As far as loan application processing is concerned, the system <strong>of</strong>fers flexible<br />
configuration options with regard to payment schedule, payment method,<br />
interest calculation, and disbursement. Apart from the base rate, a margin<br />
interest per customer-product-relation can be added. The user can also define<br />
the verification <strong>of</strong> security using borrowers’ shares, collateral, and guarantors<br />
and the prioritisation <strong>of</strong> payments in case <strong>of</strong> delinquency. The system features<br />
what-if analysis to illustrate the change in payment schedule given different<br />
assumptions and choices. However, the system <strong>of</strong>fers only limited features to<br />
present the outcome <strong>of</strong> the appraisal process or any details on the outcome.<br />
The user cannot easily understand why an application was rejected and<br />
what the applicant could do to be eligible. Whenever details <strong>of</strong> a particular<br />
loan such as payment method are changed, the payment schedule seems<br />
to only be adjusted after the end-<strong>of</strong>-day (EOD) procedure is completed.<br />
Additionally, the system would need customisation for suspending interest<br />
beyond a certain period <strong>of</strong> delinquency. While the system can classify loan<br />
performance according to the WOCCU categorisation, it does not <strong>of</strong>fer credit<br />
scoring functionality and only very basic collateral management. The system’s<br />
accounting functionality is deemed sufficient. The CoA is fully customisable.<br />
Moreover, the system enables the user to specify how transactions are to be<br />
posted based on e.g. product and transaction type. Postings can be tracked by<br />
product, branch or any other segmentation. An administration module tracks<br />
any incorrectly posted transactions.<br />
Orbit product configurations options are deemed comprehensive. As the<br />
system is a simplified and down-scaled version <strong>of</strong> Neptune’s core banking<br />
system Equinox, it is very scalable as additional Equinox modules can easily be<br />
reintegrated. The usability <strong>of</strong> the solution leaves room for improvement. The fact<br />
that FOSA, system administration, report wizard, EOD procedure, and account<br />
processing (BOSA) are different modules and need to be accessed individually,<br />
could create inefficiencies. Using two different report writers, Crystal Reports<br />
for FOSA and CENTURA for BOSA, makes usage more complex. While a clearly<br />
AUTOMATION OF SACCOS: ASSESSMENT OF POTENTIAL SOLUTIONS • 43<br />
structured toolbar facilitates navigation, labelling is deemed insufficient,<br />
abbreviations being unclear and button labels being too short. Colour should<br />
be used for emphasis, e.g. highlighting mandatory fields. The security features<br />
<strong>of</strong> the system are considered sound. Access can be restricted on modular as<br />
well as field level. Users can also be restricted from accessing specific customer<br />
data, particular GL accounts or dormant accounts. Transactions limits can be<br />
set and authorisation processes are enabled. Restriction options for periods <strong>of</strong><br />
link downtimes help to prevent the risk <strong>of</strong> abuse where data is not coordinated.<br />
The audit trail features can be improved by using meaningful labels and not<br />
database field names. The export functionality is considered insufficient as<br />
exported data is not clearly arranged in Excel and it needs rework before it can<br />
actually be used for analysis. Moreover, the import functionality is insufficient<br />
as it does not seem to enable flexible definition <strong>of</strong> mapping different data<br />
formats and structures.<br />
Cost: Neptune <strong>of</strong>fers their solution as both local installations as well as a<br />
centralised setup under the ASP model. With regard to local installation,<br />
Neptune’s cost estimates were approximately twice as high as estimates from<br />
vendors such as Craft Silicon or Fintech. This was the case for both standard<br />
<strong>SACCOs</strong>. Although the project team is aware that the estimates can only serve<br />
as rough indication, the price difference between the mentioned vendors<br />
seems substantial. Also with regard to the ASP option, Neptune’s asking price<br />
is considered relatively high. Taking the provided information into account,<br />
the project team estimated the cost for the two standard <strong>SACCOs</strong> to amount<br />
to almost the same price they would need to pay when acquiring Bankers<br />
Realm or FinSacco, with the substantial difference that they did not own an<br />
asset at the end <strong>of</strong> the year. From year 2, the estimated costs for a continued<br />
use <strong>of</strong> Neptune’s service would be almost five times higher than the annual<br />
maintenance fees <strong>of</strong> one <strong>of</strong> the other vendors, meaning the putative cost<br />
advantage <strong>of</strong> engaging an ASP could not be realised in this case.<br />
Application maintenance and support: The support structure in<br />
place seems to be appropriate. Neptune has more than 30 staff in their Nairobi<br />
<strong>of</strong>fice that can support implementations as well as maintain and develop the<br />
application further. Their specific experience is still limited, as Orbit has only<br />
been implemented in two <strong>Kenya</strong>n <strong>SACCOs</strong> so far. It needs to be stressed that<br />
none <strong>of</strong> them is operating on the ASP model yet but have local installations.<br />
Embu Farmers’ SACCO is scheduled to go live on the ASP model some time<br />
next year. It will then need to be confirmed that Neptune can deliver the<br />
proposed service.<br />
recommendation: To conclude, Neptune’s solution Orbit <strong>of</strong>fers the<br />
functionality necessary to support a SACCO’s operations. However, there<br />
is room for improvement with regard to fully integrating the solution and<br />
making it more SACCO-specific. Given the observed price difference between<br />
Neptune’s estimates and those <strong>of</strong> other vendors such as Craft Silicon or Fintech,<br />
the project team only recommends Orbit as a secondary option as there seem