Search for credit risk software and half of what comes back is built for a different risk. Accounts-receivable and order-to-cash suites manage trade credit for your own customers: credit applications, customer credit limits, blocked-order release, DSO and collections dashboards. Useful if you invoice on terms, irrelevant if you lend money. Lenders are asking a narrower question, and it is rarely about analytics: where does our credit risk policy actually run, and who is allowed to change it?
On paper the policy is governed. The credit committee approved score and PD cutoffs, exposure caps per borrower, product, and sector, collateral and DSCR floors, override authority by approval level, and the review cadence each risk grade triggers after booking. In production that document is scattered: a few conditions hard-coded in the origination service, a cutoff configured inside a scorecard vendor's console, an overlay spreadsheet the credit team maintains by hand, and an exception register somebody rebuilds before every board pack.
The market answers with size. Credit risk management software suites bundle spreading, rating models, portfolio analytics, and a decisioning module you configure through the vendor's professional services queue, so moving one threshold becomes a change request with a delivery date. Scoring vendors sell the model and stop at the score. The rules in between, the ones that actually approve, decline, refer, cap, and escalate, end up owned by whoever last touched the code.
The gap shows up under examination. SR 11-7 and OCC Bulletin 2011-12 put real change control around the model, yet the policy layer consuming its output often has weaker governance than the model itself. The OCC expects the board credit committee to monitor loan policy exceptions, and persistent underwriting exceptions read as a fair lending flag as well as a credit one. If nobody can say which version of a cutoff was live in March, who approved it, and how many exceptions it produced, the answer is a folder of emails.
