Bank Regulatory Reporting Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does scoping the forms instead of the mapping layer happen so often?

A bank decides it needs Call Report automation, and the project that gets written describes schedule assembly. Somebody will rebuild Schedule RC, RC-C, RC-R and the memoranda items, validate the arithmetic, and produce a submission file. That is the visible part of the job, so it is the part that gets specified, quoted and funded.

It is also the part that is already a commodity. The FFIEC maintains the forms. Wolters Kluwer OneSumX, Nasdaq AxiomSL, Regnology and Fiserv Prologue all maintain them too, and they update when the forms change, which they do. A team that spends its first release rebuilding schedule logic has bought something it could have rented, and it runs out of budget at exactly the point the real work starts.

The real work is the mapping layer. A regulatory line item is almost never one general ledger account. It is a rule with exclusions, participations tested for true sale, and a carve out for one restructured relationship. That rule carries accounting judgement made in a meeting years ago, and it now exists as a nested formula with a cell comment. Nobody can restate it, so nobody can automate it.

The fix is a scope sentence, written before anyone quotes. First release covers automated extraction, an effective dated mapping layer, and variance review that drills to source records. Schedule maintenance stays wherever it lives today. Banks that write the scope this way ship in 14 to 18 weeks at $85,000 to $190,000 in our experience. Banks that scope the forms first spend the same money and still assemble in a workbook.

What goes wrong when you migrate chart of accounts mappings and prior filings?

Migration in this category is not a data load. It is a translation exercise, and the source language is undocumented. Three hundred mapping rules exist as formulas, and a formula tells you what happens without telling you why. Move the formula and you have moved the defect too, because the reason the exclusion exists is the part an examiner will ask about.

Two things make it harder than teams expect. First, acquisitions. A second chart of accounts is not a merge, it is a second complete set of judgement calls, and the products rarely line up cleanly with yours. Second, history. Prior filings usually exist as saved submission files and PDFs, which are documents rather than data, so they cannot be regenerated and cannot be compared.

The fix has three parts. Migrate rules as declarations with a required rationale field, a named owner, an effective quarter and an approver, so nothing crosses over without a reason attached. Run one full quarter in parallel with the workbook and reconcile line by line, budgeting for the fact that this quarter will be slower than usual. And archive every filing as an immutable snapshot with the mapping version pinned to it, so the filing you submitted can be reproduced from data years later rather than retrieved as a picture.

Why do core, loan and investment extracts break after launch?

They break on as of dates before they break on anything technical. The loan servicing report was run on a Tuesday, the general ledger extract on a Wednesday, and four charge offs happened in between. Nothing errored. The schedules simply disagree by a few hundred thousand dollars, and an analyst spends an evening comparing exports row by row to find out why.

The second cause is delivery mechanics. A Jack Henry, Fiserv or FIS core often exposes reporting data as a fixed width file dropped on SFTP overnight rather than through an interface. Investment accounting is a third system with a third taxonomy. When the core vendor ships a release that adds two columns, the parser either fails loudly, which is fine, or silently shifts a field, which is not.

The fix is to treat every extract as a contract. The as of date is declared by the source and enforced by the system, and schedule assembly refuses to run when two feeds disagree on it. Every file carries a row count and a checksum that must reconcile before the data is accepted. Column layout is validated against a stored schema, so drift raises an alert on the day it happens instead of surfacing as a variance three weeks later. None of this is difficult. It is simply the part that gets cut when the demonstration is the priority.

What happens when validation edits and top side adjustments are not covered?

The Central Data Repository runs its edit checks when you submit. That is a bad moment to discover that Schedule RC-R does not reconcile to Schedule RC. The common workaround is to submit early, read the edits, then amend, which works right up to a quarter with no slack in it, and every bank eventually gets one.

The quieter problem is top side adjustments. Every reporting team has them: a reclassification agreed with the controller, a correction that could not be posted before close. In a workbook they are a typed number in a cell. There is no reason, no approver, and no expectation of reversal, which means the filing cannot be tied back to the general ledger and the following quarter inherits an adjustment nobody remembers making.

The fix is to move both controls earlier. Run the published edit set locally against draft data at several checkpoints during the close so failures appear while there is still time to fix the source rather than plug the schedule. Carry your own internal edits alongside them, the ones your controller added after past problems, such as past due totals never exceeding outstandings by category or allowance movement equalling provision minus net charge offs. Those catch more real errors than the published edits, because the published edits test arithmetic and yours test reality. Then model every top side adjustment as an approved journal with a reason, an approver and a reversal expectation, so the filing reconstructs itself from records rather than from memory.

Should you build custom or configure what you already own?

If you are a community bank under roughly $1B in assets with one core, one loan system, no acquisitions in the last five years, and a preparer plus a reviewer who both understand the mappings, configure. OneSumX or Regnology will cost less than a build and will carry schedule maintenance forever, which is genuine value because the forms change and somebody has to track it. Spending $150,000 on software to save a preparer eight days a quarter is poor arithmetic at that size. Hire the second preparer and document the mappings properly.

The same advice applies if your last examination raised no reporting findings and your close already lands comfortably inside the 30 day deadline. A workbook that works is not a crisis, and replacing it introduces risk you are not currently carrying.

Build, or more precisely build the layer underneath, when two or more of these are true. You have grown through acquisition and carry more than one product taxonomy. Your source systems cannot deliver a conformed extract without a person massaging it. Your last examination produced a finding on reporting controls or documentation. You cannot reproduce a filing from two years ago from data rather than from a saved PDF. Or preparation is consuming more than about 15 working days per quarter across the team.

For most banks in the $3B to $30B range the right answer is a hybrid: keep the vendor for the forms and the edits, and build the extraction, mapping, lineage and variance layer that feeds it. The forms are a commodity. Your chart of accounts and the judgement encoded against it are not, and that is precisely the part every vendor hands back to you.

How do hidden costs get into the quote?

The first hidden cost is source system count, and it is usually undercounted. Teams say core, loans and deposits, then remember investment accounting, then the wealth subsidiary, then the participations register a relationship manager keeps. Each one is an extraction problem with its own delivery mechanism and its own reconciliation.

The second is the second chart of accounts. If an acquisition is in your history, mapping work roughly doubles and the merge is never clean. The third is securities and derivatives, because classification and risk weighting on Schedule RC-R carry judgement that has to be captured rather than coded. The fourth is a reporting threshold you have crossed or are about to cross, since new schedules mean new subject matter expertise on both sides of the table.

Two more get missed almost every time. The parallel quarter is real work for your team, not just ours, and it should be a line in the plan rather than a surprise in month four. And the discovery effort of writing down three hundred mapping rationales is measured in weeks of your preparer's time. Ask for those six items to be priced or explicitly excluded in writing. A quote that does not mention them is not cheaper, it is less complete.

What separates a build that works from one that fails here?

The successful ones model lineage before they model screens. Ask a developer to draw it on a whiteboard, and the answer you want describes a source record, a mapping rule version, a computed line item and an archived filing snapshot, walkable in either direction. If the conversation starts with dashboards, they have understood this as reporting rather than as a control, and you will get a nice interface over the same unexplainable numbers.

They also treat history as immutable. Ask what happens on a restatement. The correct answer is that prior period data never changes, corrections are new versioned facts, and both the original and the amended filing remain reproducible. Anything that overwrites history is disqualifying in this domain, regardless of how neat it looks.

They name their integrations. A Jack Henry core, a separate loan origination and servicing platform, and an investment accounting system are three different problems, and at least one will arrive as a file on SFTP at 4am. A developer who claims integrations in general has not done this.

Finally, they settle ownership before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. For a system whose entire purpose is proving how a filed number was produced, hosting your reporting logic inside somebody else's account is a control weakness an examiner will eventually name.