A bank has the same knowledge problem as anybody else and one extra constraint on top of it: parts of what its people need to look up are also parts of what a supervisor expects to be documented, dated and followed. Treating the whole base as one undifferentiated pile is what makes both jobs harder than they need to be.
Two populations of article, one search box
Most of a bank's base is ordinary: how to reset a teller terminal, who owns the wire template, what to tell a customer about a hold. A minority is procedure that sits underneath a control, and that minority has different rules about who may change it, who approves the change and how long the superseded version is kept. The search box should serve both; the governance behind them cannot be the same.
The supervised minority needs version history, not just an owner
For an ordinary article, knowing who owns it and when it was last checked is enough. For a procedure that supports a control, you need to be able to say what the procedure said on a given date and who approved it saying that. If the product cannot show a prior version and the approval that accompanied it, that class of article does not belong in it.
Model and vendor documentation is a neighbor, not a tenant
Supervisory expectations around model documentation and third-party risk produce a large amount of writing, and it is tempting to put it in the base because the base is where writing goes. Resist it. That material has its own review cadence, its own audience and its own retention, and burying it among articles about terminal resets makes it harder to produce when somebody asks for it.
Customer-facing answers are the highest-risk articles you have
What a front-line person tells a customer about a fee, a hold or a dispute is regulated speech in effect if not always in form. Those articles deserve the tightest ownership in the base: a named owner in the business line, a review date that is enforced rather than aspirational, and a rule that a change goes live only after the owner has seen it.
The realistic structure
One base, two governance tiers, and a visible badge on the tier that is supervised so nobody edits it casually. The alternative people try first is two separate systems, and it fails for a predictable reason: staff search the one they use daily and never learn the other exists, so the supervised procedures go unread until an examiner asks.
Questions people ask about banking knowledge management
Should the supervised articles live in the policy system instead?
The approved policy should. The working procedure people read at their desk usually should not, because policy systems are built for acknowledgement rather than for looking something up in twenty seconds. Link the two rather than duplicating them.
Who should own a procedure article?
Somebody in the business line who performs the work, with a second approver from the function that answers for the control. An owner in a central documentation team produces articles nobody in the line believes.
How long should superseded versions be kept?
As long as the record the procedure supports. That is a retention question your records schedule already answers for the underlying record, and the procedure inherits it rather than getting a number of its own.
Does this change which product we can buy?
It narrows it. You need per-article versioning with an approval trail and the ability to export a version as it stood. A product that only shows the current text and a modification date cannot answer the question a supervisor will ask.