Every product in this category demos the same way: a dashboard, a green tick, a submission button. The differences that matter are underneath, and they are the same four things whatever the regulator and whatever the return. This page is those four, in the order they bite, so a demo can be steered at the parts that will actually hurt in month three rather than the parts that look good in month one.
Collecting the data from systems that were not built to give it
The return wants figures in the regulator's shape, and the business keeps them in the core system's shape. Everything else in the category is downstream of how the gap is crossed: an export somebody edits, a mapping somebody maintains, or a feed nobody touches. Ask which, and ask who owns the mapping when the core system is upgraded. That answer predicts more about the next two years than any feature list.
Applying the form's rules, including the ones that change
Forms are versioned and the rules move. What matters is not that a product supports the current version but how quickly it supports the next one, and whether your data has to be reshaped when it lands. A product whose validations are configuration ages differently from one whose validations are code. This is worth an explicit question because both look identical in a demo of the current form.
Keeping the evidence a figure rests on
A number in a return is only as defensible as the working behind it, and the moment anybody queries it the question is what the figure was derived from and who checked it. A solution that stores the submitted file and nothing else has solved the easy half. The useful test: can it show, for a figure filed eighteen months ago, the source extract and the person who approved it, without anybody going to a backup.
Proving what was filed and when
The submission receipt, the version submitted, the date, the person. This is the part every product claims and the part worth testing hardest, because it is the one an examiner asks for and the one that is most often a folder on a shared drive with a naming convention. If the answer to what was filed on this date is a search of somebody's mailbox, the product is not doing this.
The Call Report, as the worked example
Every insured depository institution files the Consolidated Reports of Condition and Income each quarter, on one of three forms: FFIEC 031 for a bank with foreign offices, FFIEC 041 for a domestic bank, FFIEC 051 for a smaller domestic institution that qualifies for the reduced form. The due date is thirty calendar days after quarter end, and the schedules are versioned by the agencies several times a year. That one return is a fair test of any product in this category, because it exercises all four things above at once: figures drawn from the general ledger and the loan system, a form whose line items and edits change, a set of figures an examiner will trace back to source, and a submission whose receipt has to be produced on request. Ask a vendor to walk the last two quarters of your own Call Report through their product, edits and all, and most of the selection is done.
What the price actually pays for
Three things move the cost of one of these products and none of them is the license. The number of source systems, because each one is a mapping somebody maintains. The number of forms, because each one is a set of versioned rules that has to be kept current. And the number of people who touch a return, because that is what the review and approval workflow is priced on. A single-form institution with one core system is a small problem and should pay a small price; a group filing on twelve forms from four systems is buying a mapping team whether the invoice calls it that or not. Sizing the quote against those three numbers, rather than against the vendor's tier names, is the fastest way to see whether it is expensive.
The demo questions, in the order they bite
Who maintains the mapping when our core system is upgraded, and what did that cost your existing customers last time. Show us the last form version change: how long between the agency publishing it and your product supporting it, and did customers have to reshape data. Show us a figure from a return filed a year ago on a customer's system: the extract it came from, the adjustments, the approver. Show us the submission receipt for that return, and where it lives. Then, only then, show us the dashboard. A vendor who can answer the first four from a real account rather than a slide is selling the product this category is supposed to be.
Questions people ask about regulatory reporting solutions
Do we need a dedicated product at all?
Below a handful of returns a year, a spreadsheet and a calendar genuinely work. The point at which they stop is usually when the person who built the spreadsheet leaves.
How do we compare two regulatory reporting tools fairly?
Run both against a return you have already filed and compare their output to what you actually submitted. A demo on the vendor's data compares nothing.
What is the most common thing missed in selection?
Who maintains the mapping when the source system changes. It is nobody's favorite question and it is the one that decides the running cost.
Does one product cover a bank’s Call Report and an adviser’s Form ADV?
Rarely well. A depository institution's quarterly returns and an investment adviser's filings under the Advisers Act rules are different forms, different regulators and different data, and a product built for one usually treats the other as an afterthought. Buy for the returns you actually owe, and keep the filing calendar itself in one place whatever prepares each return.