Banking Software Evaluation Guide
Start with what your bank needs to change. Use four questions to compare vendor scope, test a claim and find the Bankware products worth a closer look.
What actually needs to change?
Start with the work your institution wants to do differently. The same lending problem can call for a new core, a specialist lending solution or a change to how products are configured.
Do we need a new core to change loan origination?
Not necessarily. Compare Core Banking Suites when several banking domains need to move together. If the gap runs from loan application to servicing, assess General Lending and the handover to retained systems. If the issue is defining rates and conditions, examine BX-PF and confirm that your processing system can execute the resulting rules.
Identify the point where the servicing system books the loan. Ask the General Lending team to trace an approved application into a booked contract, including who owns the terms and how a rejected handover is corrected.
What is included in the proposed delivery?
Ask vendors to distinguish what comes with the product, what can be selected and what must be built or integrated. A capability on a product page does not settle the scope of a project.
Can we renew our retail core and keep our existing channels?
Yes. The Retail Bank Suite treats Customer Mobile App and Internet Banking as optional, so a bank can retain its channels. The Digital Bank Suite includes both in its default delivery. In either case, agree the customer journeys, adaptations and interfaces for your bank.
For the Digital Bank Suite, select the customer journeys and confirm their external dependencies. For digital onboarding, identify who supplies identity verification, who integrates it and what happens when an applicant needs manual review.
Choose a rule your bank changes regularly, such as a loan rate. Ask the vendor to show the setting in the proposed product version and run a transaction with the new rate. Record any extension, interface or code change separately in the proposal.
What stays in place, and who owns the handover?
Follow a transaction across systems, including the point where it can fail. An interface diagram shows the connection; an evaluation should also identify who detects an exception and reconciles the result.
Must we replace our integration platform to use BX-CBP?
No. BX-I is optional in BX-CBP-based offerings. A bank can retain an agreed integration product. For example, when a payment request times out, ask the vendor to trace the request, show how the bank checks whether it posted and identify who can safely retry it.
Rehearse migration with a small set of contracts, including one with an overdue instalment. Compare balances, schedules and accounting entries in both systems. Agree who resolves discrepancies and what must reconcile before the bank approves cutover.
What would give us confidence in the fit?
Use a reference to establish what a vendor has delivered. Then test the proposed product against a transaction, exception and operating constraint from your own institution.
What can a Bankware customer reference tell us?
K-Bank’s launch illustrates core banking delivery using BX-CBP and BX-PF. Geely Auto Finance illustrates a different engagement: automotive financing supported by BX-AFS. Neither reference defines today’s product scope. For an auto lender, a useful next test is to follow a dealer quotation through contract creation, billing and collections.
Compare the customer’s business model, the product version delivered and the systems it retained. For example, use the Geely engagement to discuss automotive finance, then ask which dealer and servicing workflows the proposed Asset Finance version covers today.
Keep the scenario, sample inputs, expected result and actual result together. For each gap, record the proposed change, the responsible team and how the bank will verify it. That gives competing vendors the same test.