Certificate of insurance tracking software exists to make sure every loan's collateral stays insured the way its agreement requires, and most of the market does half of that: it stores the carrier, the policy number, the expiry date and a limit, and reminds somebody when the date comes round. The half it leaves out is the half that produces losses — whether the bank is still named in the right box, whether the limit still matches the covenant, whether the deductible is inside what was agreed, whether every location is scheduled. Botminds' Collateral Insurance & Lien Tracking is built on the reading rather than the diary, and this page is written as a buyer's brief rather than a pitch: twelve questions, the answers that should worry you, and an honest account of what a bank still owns after it buys anything at all.
The product examples come from a fictional sample bank as it runs through the solution — Kestrel Valley Bank, 1,846 commercial loans, $2.31 billion. The people, banks and agents are sample data. The supervisory figures are published, and linked where they appear.
Why the examination picture belongs in the business case
131
violations of the flood act and 12 CFR part 339 cited by FDIC examiners in 2025
3rd
most-cited body of consumer compliance rules that year, behind lending disclosure and electronic fund transfers
875
violations in the five most-cited groups together, of 1,155 cited in all
462vs 136
the two groups ahead of flood: lending disclosure, then electronic fund transfers
What certificate of insurance tracking software has to do
Six things, and a product can be excellent at the first two and useless at the rest. It has to receive evidence in the forms it actually arrives in — PDFs by email from several hundred agencies, not a feed. It has to know what each loan requires, which is prose in a credit agreement rather than a field. It has to compare the two. It has to chase what has not come. It has to draft the correspondence that follows. And it has to leave a file that someone outside the desk can read in an hour.
Almost every product in the category does the chasing and the diary. The differences that matter sit in the second and third of those six, and a demonstration is designed not to dwell there. The questions below are the ones that bring a demonstration back to them.
Does it read the certificate, or only store the date?
Ask it directly, and then ask the follow-up that settles it: where did this limit come from on the page? A product that reads will show you the document with the value marked on it. A product that stores will show you a field that somebody — an analyst, an offshore keying team, the agent through a portal — typed, and the honest ones will say so.
The distinction is not academic, because the failures are different. A date store fails silently at renewal: a borrower moves to a new carrier and a new agency, the certificate arrives on time, the dates are good, and the bank has quietly stopped being a mortgagee. Nothing in a diary notices that. A document reader fails loudly, on a bad scan or an unfamiliar form, and a loud failure is one a desk can work with.
The wording questions: clause, named insured, deductible, locations
Four questions, and they are where the money is. Ask each one as a demonstration task rather than a capability question, using a certificate of your own.
The clause. Does it check the mortgagee and lender's loss payee wording word for word against what your agreement requires, including the ISAOA/ATIMA construction, and does it treat the certificate holder box as a different thing from additional interest? A bank named only as certificate holder has no rights under the policy at all — no claim payment and no notice of cancellation — which is the single most expensive misreading in this field, and what a certificate holder actually gets is worth reading before any demonstration.
The named insured. Does it compare the insured on the policy with the borrowing entity on the loan, rather than with the trading name? A hotel insured in the operator's name, with the borrowing property company nowhere on it, passes every date check ever written.
The deductible. Does it test the deductible against the ceiling the agreement sets, including percentage deductibles on wind and hail, which are the ones that move? A 5% wind and hail deductible on a building where the covenant allows 2% is a six-figure difference on a coastal property, and it is stated on the certificate in small print.
The locations. Does it read an attached schedule and test the limit for each building, or does it compare one blanket limit with one required figure? Multi-property borrowers are where tracking desks lose their footing, and the attached schedule is where the answer lives.
Does it hold flood clocks and lien windows in the same place?
Ask whether the product is an insurance tracker that has a flood field, or a collateral compliance system in which flood and Article 9 are first-class. The test question is simple: show me a loan where a certificate renewal, a flood determination and a financing statement are all in play, on one page, with the dates for each.
Flood is not a kind of hazard insurance for this purpose; it is a separate rulebook with its own required amount per building, its own notice, its own period before placement and its own evidence rules — the regulation is explicit, for instance, that a declarations page showing the policy number and the insurer or agent is sufficient proof and must be accepted (12 CFR § 339.7(b)(2)). A product that stores a flood policy expiry date beside the property expiry date has modelled flood as insurance and will be wrong in the ways that get cited.
Financing statements are further still from a certificate, and further from most products. A lapse date is not a renewal date: it is set by a filing office, it moves only by a continuation, and the window in which that continuation counts is narrow and unforgiving. Where the lapse date comes from explains why the one in a loan system is so often wrong, and why a tracker that imports it without reconciling it has imported an error rather than a date.
Three kinds of product against the twelve questions
| The question | A date store | A document reader | An agentic desk |
|---|---|---|---|
| Where does the data come from? | Keyed by a person or an agent portal. | Read from the document. | Read from the document, with page and position kept. |
| Where does the requirement come from? | A template the bank fills in once. | A template, usually. | The loan agreement itself, section by section. |
| Compared with last year? | No. | Sometimes. | Yes — the clause that was there and is not. |
| Mortgagee wording checked? | No. A clause is not a date. | Often, against a standard form. | Word for word against your required wording. |
| Certificate holder vs additional interest? | One field for both. | Usually separate. | Separate, and a bank in the wrong box is a gap. |
| Schedule of locations? | One blanket limit. | Reads the schedule. | Tests the limit for each building. |
| Flood determinations and required amounts? | A date field. | Stores the policy. | Amount per building, and the period to placement. |
| UCC lapse dates and windows? | Not held. | Not held. | From the filing office acknowledgment, with the window. |
| Whose lead times and ratings? | Fixed by the product. | Configurable. | Settings, each change kept as a new version. |
| What can it do unattended? | Email reminders. | Email reminders. | Read, compare and draft. Never send, file, place or except. |
| Can a value be traced to its source? | To whoever keyed it. | To the document. | To the document, page and position. |
| What comes back if you leave? | A spreadsheet of dates. | Dates and documents. | Documents, extracted values, correspondence and the dates behind every action. |
Whose rules are they? Lead times, ratings, binders and approvals as settings
A tracking system encodes a credit policy whether or not anyone admits it. When the first renewal request goes out, how long a binder is good for, what insurer rating is acceptable, how flood amounts are allocated, how early a continuation must be filed — each is a policy choice, and in most products at least some of them are the vendor's choice, buried.
Ask to see the settings screen, and ask three things of it: which rows are ours, which are fixed by regulation, and what happens to the old value when we change one. At the sample bank the first request to the agent of record goes at 45 days before expiry, with 30 and 60 as the alternatives; the second request, to the agent and the borrower, at 15 days, with 10 and 20; the minimum insurer rating is A− VII; a binder is accepted as evidence for 30 days; the flood required amount is calculated per building rather than allocated across them; continuations are filed no later than 60 days before lapse; and state records are checked weekly for name changes. One row is not a choice and says so on its face — the period from a flood notice to placement, which is fixed by regulation. Every change is kept as a new rule version on the audit trail, which is the part an examiner cares about, because the question will be what the setting was in March, not what it is today.
The settings screen: which rows are the bank's, and which are not
What stays with the bank when the tracking is outsourced
Everything that matters. This is the question buyers skip and second-line reviewers do not, and the supervisory answer is unambiguous.
"Effective third-party risk management includes ongoing monitoring throughout the duration of a third-party relationship, commensurate with the level of risk and complexity of the relationship and the activity performed by the third party."
Interagency Guidance on Third-Party Relationships: Risk Management, 88 FR 37920 (9 June 2023)
Read as a buyer, that sentence has a practical edge: the diligence does not end at selection, so whatever you are shown in a demonstration you will also have to be able to see every quarter afterwards. That is an argument for a system whose work is legible from the outside — one where a reviewer can open any finding and see the document it came from — and against one whose quality can only be asserted. It is also the reason to ask what reporting you get about the system itself, as distinct from reporting about your loans: how many documents were unreadable, how many drafts were corrected before sending, how many exceptions are open past their review date.
The corollary is worth saying plainly to anyone building the business case. Buying this software does not transfer the obligation to keep the collateral insured and the liens perfected. It changes who does the reading, the comparing and the drafting, and it makes the evidence easier to produce. The bank still owns the outcome, which is exactly why the authority boundary — what the software may do without a person — belongs in the contract and the procedure, not only in the product. What agents read, draft and never send sets that boundary out as nine rules.
What you have to bring: agreements, templates, required wording, a sample of documents
A selection runs badly when the bank arrives with nothing but a loan list. Six inputs make the difference between a demonstration and an evaluation, and five of them already exist somewhere in the building.
What to bring to the evaluation, and why each one earns its place
- Twenty loan agreements, unredacted
Including two badly drafted ones and one with an amendment that changed the insurance section. The requirement is prose; this is how you find out whether the product can read prose.
- Your required mortgagee and loss payee wording
Exactly as your counsel words it, with the ISAOA/ATIMA construction you use. Clause checking is only meaningful against your clause.
- A hundred documents as they actually arrive
Certificates, declarations pages, endorsements, binders and flood determinations — including a fax scan, a certificate with a twelve-location schedule and one that is simply the wrong document.
- Your notice and request templates
The letters you send today. If the product cannot draft in your voice and cite your clause numbers, somebody will retype every letter.
- A list of financing statements with their file numbers
So the lien side can be tested against the states, not described. The file number is the key that survives a debtor name change.
- Your settings, written down before the demonstration
Lead times, insurer rating, binder life, flood amount rule, filing deadline, who approves what. If the product cannot hold them, it is asking you to change policy to suit software.
How to test it before you sign: a replay on files you have already closed
Run the hundred documents through the product and compare its verdict with what your desk concluded at the time. Score four outcomes rather than two, because the interesting ones are not the misreads.
What a demonstration shows, and what a replay on your own closed files shows
The demonstration: The vendor’s samples: clean, modern, on the forms the product was built against.
The replay: Yours: the fax scan, the renewal from a new agency, the certificate for an entity that changed its name.
The demonstration: A template requirement, entered in advance.
The replay: Your agreement’s own section, with the amendment that changed it.
The demonstration: That the screen fills in.
The replay: Four outcomes: agreed, product found a gap your desk missed, product missed a gap your desk found, product confidently wrong.
The demonstration: None. A demonstration has no outcomes.
The replay: Confidently wrong. One of these in a hundred is a conversation about how the product says "I don’t know".
The demonstration: Not available.
The replay: Gaps your own desk missed. Expect some, and budget for the remediation they imply.
The demonstration: The vendor, narrating.
The replay: The tracking specialist and the flood officer, with the files open. Nobody else can tell which verdict was right.
Two practical notes on running it. Do not tell the product which documents are the awkward ones; the point is whether it says so itself. And keep the scored sheet afterwards — it becomes the baseline you re-run at the first quarterly review, which is the ongoing monitoring the guidance asks for, done with almost no extra effort.
Twelve questions for a certificate tracking vendor
In this order, because each answer changes what the next one means. The first four are about reading, the next three about scope, the last five about authority and exit.
Twelve questions, each with the answer that should worry you
- Where did this value come from on the page?
Worrying answer: "it is in the system." A value without a position was typed, not read.
- Show me a certificate where the bank is only in the certificate holder box.
Worrying answer: a pass. That is the renewal failure this whole category exists to catch.
- Check this mortgagee clause against our required wording.
Worrying answer: a tick with no text comparison. Ask to see the two strings side by side.
- Here is a schedule of twelve locations. Which building is short?
Worrying answer: a single blanket limit compared with a single required figure.
- Where does the requirement come from?
Worrying answer: a template the bank maintains by hand. Agreements get amended; templates do not.
- Show me flood: the required amount for this building, and the period to placement.
Worrying answer: a flood policy expiry date in the same table as the property policy.
- Show me a financing statement’s lapse date and where it came from.
Worrying answer: "we import it from your loan system." That is the field most likely to be wrong.
- Which of these rules are ours, and what happens to the old value?
Worrying answer: settings that overwrite silently. An examiner will ask what the rule was in March.
- What does the system do without a person?
Worrying answer: "it can send the notices for you." Ask whether it can be prevented from doing so, and how you would prove it.
- What happens when a document is unreadable?
Worrying answer: a default, a blank, or last year’s value carried forward.
- What do we have to give you to start, and how long before it reads our agreements?
Worrying answer: a date with no inputs attached. Ask which of the six inputs above drives it.
- What comes out if we leave?
Worrying answer: a report. Ask for the documents, the extracted values, the correspondence and the dates behind every action.
What the desk looks like when the reading is done: one morning, every verdict
Twelve months of dates, each read from the document behind it
One closing word on how to use this page internally. The strongest case for changing anything here is not efficiency; it is that flood is a small body of rules that produces a disproportionate share of examination findings, and that a lapsed financing statement turns a secured loan into an unsecured one retroactively. Put those two sentences at the top of the paper and the twelve questions underneath. To see how one solution answers them, start from Collateral Insurance & Lien Tracking.
Questions people ask
What should certificate of insurance tracking software do?
Receive evidence in the forms it arrives in, know what each loan's agreement requires, compare the two including against last year's evidence, chase what has not come, draft the correspondence that follows, and leave a file a reviewer can read. Most products do the chasing and the diary well. The comparison against the agreement — wording, limits per building, deductibles, named insured — is where they differ, and it is where the losses are.
Does the software read the certificate, or just store the date?
It varies, and the question has a precise test: ask where a given value came from on the page. A product that reads will show the document with the value marked; a product that stores will show a field that somebody typed, whether a bank analyst, an outsourced keying team or the agent through a portal. The difference shows up at renewal, when a new carrier drops the mortgagee clause and nothing about the dates looks wrong.
Can it check the mortgagee clause wording?
Ask for it as a demonstration task, with your own required wording and your own certificate. What you want to see is the two strings compared, not a tick. The related check is whether the product separates the certificate holder box from additional interest: a bank named only as certificate holder has no rights under the policy, and a system that treats the two boxes as one field cannot tell you so.
Does it handle flood and liens as well as property insurance?
Ask, because many are built around property certificates alone, and the answer is a fair reason to narrow a shortlist. Flood has its own required amount per building, its own notice, its own period before cover may be placed and its own evidence rules. A financing statement has a lapse date set by a filing office and a window for continuation that is short and unforgiving. Both live on the same loan as the certificate, and a bank that tracks them in three places reconciles them in none.
Can we set our own renewal lead times and insurer rating?
In a product worth buying, yes — and the follow-up question is what happens to the previous value. Lead times, minimum rating, how long a binder counts as evidence, how flood amounts are worked out, the latest date for a continuation and who approves what are all credit policy, so they should be the bank's settings, and every change should be kept with the person who made it. One row should not be adjustable at all: the period from a flood notice to placement is fixed by regulation.
How do you test a tracking system before you buy it?
Replay a hundred documents you have already processed and score four outcomes: agreed, the product found a gap your desk missed, the product missed a gap your desk found, and the product was confidently wrong. The last is the one to dwell on, because it tells you how the system behaves when it does not know. Keep the scored sheet; re-running it each quarter is the simplest ongoing monitoring you will ever set up.