Banking software for files, approvals, and follow-up

The unit of work is the file. A file has an applicant, a product your team already sells, an amount requested, a status, and a list of documents. Status moves only when a rule you defined is met: documents complete, a named role approved, or a named role declined with a reason. The file keeps every status change, who made it, and when. That trail is the point. A spreadsheet can store a balance. It cannot show who changed the balance after the committee.

The document checklist is specific to the product. A hire-purchase file and a staff-loan file should not demand the same uploads, and a missing guarantor letter should block the approval button rather than appear as a surprise in the committee pack. Staff can see which items are in, which are rejected as unreadable, and which are still outstanding. The applicant is chased from that list, not from memory.

Follow-up is a queue, not a mood. After approval, the file can show conditions still open, a drawdown date, and a collection note when a payment the team expected has not been marked received. After a decline, the file shows the reason and stops accepting silent edits that turn a no into a yes. None of this posts money. A payment is recorded when your team says it was received, through the bank account you already operate.

Most teams already have a path, even if it is informal. A salesperson or a branch officer opens the file. An administrator checks documents. A credit person recommends. A manager or a committee approves above a threshold. Banking operations software should encode that path, including the threshold, and should refuse to skip a step because someone is in a hurry on a Friday. The hurry can be a recorded exception, with a reason and a second approver, if that is truly how you work.

The file should be readable by the next person without a briefing call. Amount, tenor, the rate or instalment your team calculated, the collateral description, and the open conditions belong on the first screen. Supporting opinion can sit in a note. If the real opinion lives in a private chat, the file is theatre. We design the screen around the decision the approver must make, and we leave the chat for questions that are actually questions.

Declines and withdrawals need the same care as approvals. A withdrawn file should not remain in the pipeline total the director sees on Monday. A declined file should not be reopened by the person who was refused, unless a defined appeal role does it. These rules sound stern. They are how a small credit team stays able to explain a number without assembling a war room.

A checklist is an operational control. It answers: did we collect the items our own policy names, and who marked them acceptable? It might include an identity card, a company registration extract, bank statements the applicant supplied, a guarantor form, or a vehicle grant for hire purchase. The system stores the file, shows the gap, and records the reviewer.

A checklist is not a know-your-customer programme you can buy to satisfy a regulator you have not read, and it is not a tool for weakening those checks. We will not build a path that marks documents complete without a person, and we will not design screens whose purpose is to route around your compliance officer. If your policy is unclear, the audit stops until your own adviser writes the list. We implement the list. We do not author it.

Personal data on those documents should be visible to the roles that review them. A salesperson who needs the status “identity received” does not need to download the identity image months later. Export of a whole book of identity documents should be a rare, logged event. That is ordinary access control. It is also the difference between a credit operation and a shared drive named FINAL.

Approval limits are the heart of a small finance team. Below a figure, a credit manager may approve. Above it, a second person or a committee is required. The software should know the figure and the role, and the approve button should be absent when the user is outside it. A comment saying “boss said ok on WhatsApp” is not an approval. If the boss approved, the boss can tap the button, including from a phone, and the file stores that act.

The committee pack should be a view of files waiting, each with the same summary: exposure, recommendation, missing conditions, and age in the queue. Committees lose time when every officer arrives with a different spreadsheet. They lose more when a file is presented twice because nobody moved the status. One queue, sorted by age and amount, is usually the entire management report a team needs in the first release.

After the decision, conditions are not a paragraph in the minutes. They are lines on the file: “insurance assigned”, “guarantee stamped”, “vehicle inspected”. Drawdown or handover waits until those lines are checked by the role you name. This is how leasing and hire-purchase teams avoid delivering an asset while a document is still “in the branch.”

Your customers pay into a bank account you already have. The operations system needs to know which expected instalment or fee has been marked received, so collections is not guessing. It does not need to be the system that sends the money. A user matches an amount, a date, and a file. Unmatched receipts sit in a queue for finance. Overpayments and short payments are visible as differences, not as edited history.

The instalment schedule itself should be the schedule your finance team produced and is willing to stand behind. The software can display it and tick lines off. It should not silently recompute a regulated rate because a developer guessed a formula. If the formula is yours, written down, and tested against files you choose, a later phase can calculate it. The first release is safer when calculation stays where it is already trusted, and the workflow stops losing the PDF.

Write-offs, restructures, and legal handover are status changes with a reason and an approver. They are not a delete button. A director should be able to see, a year later, that a file moved from current to restructured, who agreed, and which schedule replaced the old one. That history is also what your auditor will ask for. A core banking suite provides this for a deposit-taking bank. A focused operations system provides it for a book that is not a bank.

Core banking platforms exist to post deposits, loans, and general-ledger entries for a licensed institution, with controls that assume a bank’s operating model. They are sold by vendors who implement that ledger. Sorable does not implement those platforms, and we do not resell them. If your requirement is a core replacement, ask those vendors.

A custom operations layer fits when the pain is the file around the loan: documents, approvals, conditions, and collections tasks. The team might still export totals to SQL Account, Autocount, or another ledger your accountant uses. That split is deliberate. The people who chase missing guarantor letters are not the people who close the general ledger, and one oversized system often serves neither well.

Spreadsheets remain right when the book is small, one person understands every row, and the approval is the same person. They stop being right when a second branch can edit the same file, or when a director can no longer tell which version was approved. The workflow audit is a look at that version problem. If we find a single owner and a short list, we will say a tighter sheet is enough.

We will not hold deposits, issue payment instruments, or connect you to a national payment switch. We will not store card numbers. We will not provide a customer-facing bank app for the public. A borrower portal, if you need one later, is a status view of their own file, not a bank channel.

We will not decide credit, set a lawful rate, or tell you whether your activity needs a licence. Those questions belong to your directors and your advisers before a software scope starts. We also will not build reporting whose aim is to hide a file from an auditor or a regulator. The trail is append-only for status changes that matter.

We will not scrape personal data from places the applicant did not give you, and we will not design a bypass for a document your policy requires. If a vendor offers that as a feature, treat it as a reason to walk away. Speed in a credit file comes from a clear checklist and a short queue, not from skipping the checklist.

Bring a blank file, a recently approved file with the documents removed or redacted if you prefer, and the approval grid you wish you enforced. We map who touches the file and where a copy is retyped. That is the workflow audit. It is free, and a possible outcome is “do not build.”

The quote names one product and one approval matrix. Application file, checklist, approvals, and follow-up for that scope often fall between RM15,000 and RM50,000 setup, plus monthly care. A second product with a different document list, a borrower portal, or an export to your ledger is additional. Time for the first release is often 8–14 weeks after approval, including a parallel run on live files while the old sheet is still the fallback.

Read the banking operations industry page if you are still deciding whether your team is this buyer. E-invoice and document-management pages on this site matter when the pain is the tax invoice or the archive, rather than the credit decision. We sequence those. A credit file that is still in chat will not be fixed by an invoice module alone.