Before you choose a core banking system, ask each vendor questions whose answers can be shown on screen rather than described in a brochure. Can anyone edit a posted entry? How is a mistake corrected? Can someone approve their own work? How is our data kept apart from other institutions’? What happens to signed loans when we change a rate? What does the audit trail prove? How do data get in and out? Which SMS providers work? What does the system not do yet? Who supports it, and where are they? The answers below are what to listen for. Under each one is how Fused answers the same question, including where the answer is “not yet”.
How to use these questions
Ask for each answer to be demonstrated on your own products, with your own numbers, not on a prepared script. Ask what the system refuses, because a system that accepts everything gives you no control. Ask for the answers in writing, so that the contract can refer to them. And put the same questions to every vendor, so the answers can be compared line by line.
1. Can anyone edit or delete a posted entry?
Why ask. If a posted journal entry can be changed, every report built on it can change without a trace, and a trial balance that agreed last week may not agree today. Ask who can do it, and whether the refusal lives only in the screens or in the database as well.
Fused’s answer. No one, through any screen or request. An entry balances or it is refused, in the application and again in the database, and the database itself refuses an edit or a delete of a posted entry. Every product event, from a disbursement to a till difference, is mapped to an account and posts through the same balance check.
2. How is a mistake corrected?
Why ask. Every institution makes mistakes. What matters is whether a correction leaves the original visible. Ask to see a reversal, and ask what happens to a printed receipt when the payment behind it is reversed.
Fused’s answer. By a reversal: a new entry that mirrors the original, linked to it, and made once. A receipt is reversed by a mirror document in the opposite series, never by editing the receipt. A till that has been counted and signed is not changed by a later reversal. See accounting.
3. Can someone approve their own work?
Why ask. Maker-checker only works if the system enforces it. Ask what stops a branch manager raising and approving the same disbursement, and whether “two approvals” means two different people. For more on this, see maker-checker in a finance company.
Fused’s answer. The person who raised an item is refused as its approver. Each institution draws its own approval flows on a canvas, one per event. A gate names the permission and office an approver needs, how many distinct people must decide, for example 2 of 3 managers at the branch, and a deadline in the branch’s working days, with reminders. Gated events include client activation, manual journals, reversals, period close, holidays, receipts, savings reactivation and collateral release. Fused does not have approval committees or an authority matrix as separate objects today. See approvals and controls.
4. How is our data kept apart from other institutions’?
Why ask. A common design puts many customers in one database and relies on every query remembering to filter by customer. Ask how many independent layers stand between your data and another institution’s.
Fused’s answer. Each institution has its own PostgreSQL database. Row-level security sits on top of that, and when a database is opened it is checked to confirm that it belongs to the institution asking. Fused is hosted on AWS. No security certification, such as ISO 27001 or SOC 2, is claimed. See security.
5. What happens to signed loans when we change a rate?
Why ask. A borrower’s contract should not change because the product table did. Ask the vendor to change a rate in front of you and show a loan signed last month.
Fused’s answer. Loan products are versioned. A draft is edited; a released version is immutable and takes effect on a date; each loan pins the version it was signed under. A rate change never reprices a signed loan. Rate charts are banded by amount, term and loan cycle, so a repeat borrower can get a better rate. For savings, a release says whether a new rate applies to accounts already open. A fixed or recurring deposit can only take a new rate on new accounts. See lending.
6. What does the audit trail prove?
Why ask. An audit log that can be edited proves nothing. Ask what would happen if someone with database access altered a past entry in the log.
Fused’s answer. Every write is recorded on a hash-chained (SHA-256) audit trail in the same transaction as the write. Each chain’s latest link is copied every minute to a separate database under a separate credential, so a rewritten chain is caught. Every record has its own history panel. There is a sign-in trail, and access reviews run as campaigns of decisions on who holds which access.
7. What happens if the connection drops in the middle of a payment?
Why ask. Branch connections fail. A retried request must not pay out twice, and a rounded amount must not drift.
Fused’s answer. Money movements are idempotent: a retried request with the same key returns the first result and cannot post twice. Amounts are exact decimals, never floating point, and every currency is held at its own ISO 4217 scale.
8. How do we get our data out?
Why ask. Your board, your auditor and your lenders will want figures the vendor did not anticipate. Ask whether you can write your own reports, and in what formats they leave the system.
Fused’s answer. Four reports are built in: portfolio at risk, repayments due, officer performance and client statement. Institutions can write their own queries in a report designer over curated, sandboxed views. Reports run as CSV, XLSX or PDF and can be scheduled daily, weekly or monthly. Outbound webhooks, signed with HMAC, send events to your own systems. Fused does not offer a public API yet, and export from every screen is not available yet. See reporting.
9. How do we move our existing book in?
Why ask. Migration is where implementations slip. Ask exactly which records can be imported, and how a bad file is caught before it changes anything.
Fused’s answer. Clients import from CSV, with a dry run that proves the whole file before anything is written. Opening balances are entered per branch and currency on the go-live date. A new institution starts from a finance-company chart of accounts. Loan-by-loan migration of an existing book is not built today; it is planned with each institution during scoping. See implementation.
10. Will it work with our SMS provider?
Why ask. You may already have an SMS provider, or want to change provider later. Neither should need a software release.
Fused’s answer. Any HTTP SMS gateway can be connected without a release. The institution writes a short script for its provider, and the script runs in a sandbox. Email goes through AWS SES, and message templates are the institution’s own. Sign-in codes are never sent by SMS: staff use an authenticator app. See messaging and integrations.
11. What does the system not do yet?
Why ask. Every system has gaps. A vendor who cannot name theirs has either not looked or will not say.
Fused’s answer. Stated plainly, Fused does not do the following today:
- Credit bureau. No CRIB or other credit-bureau integration.
- Regulatory output. No regulator returns out of the box, and no AML or sanctions screening.
- Tax and standards. No withholding tax or VAT handling, and no IFRS 9 staging.
- Language. The interface is in English. There is no Sinhala or Tamil interface.
- Apps. No mobile or offline field app, and no client portal. Staff use a web browser.
- Payments. No mobile-money or card payment connectors, and no exchange rates between currencies.
- Sign-in. No passkeys or single sign-on.
What it does do for Sri Lanka: LKR by default, Sri Lanka NIC in old and new formats with duplicates refused, Poya days and other holidays in each branch’s calendar, and gap-free receipt books for every branch.
12. Who supports it, and where are they?
Why ask. When something goes wrong at month end, you need someone who knows the system and works in your time zone. Ask who builds the product and who you will speak to.
Fused’s answer. Fused is built and supported by Evoke Labs in Mt. Lavinia, Sri Lanka, so you speak to the people who build it. Engineering is held to a test coverage floor of 96% across four levels of testing: unit, API contract, end-to-end and load. Every database change is additive, so the previous release keeps running while a new one is rolled out. See company.
What to do with the answers
Put the answers side by side. Mark each one “shown”, “described” or “not available”. A “shown” answer is worth more than a “described” one, and an honest “not available” is worth more than a vague “yes”. Then ask the vendors that remain to run your own products, a week of your own transactions and your own month-end on their system before you sign.
For the questions your board is likely to ask, see for leadership. To put these twelve questions to Fused on your own products and numbers, book a walkthrough.