What Off-the-Shelf Software Cannot Do for a Merchant Portfolio

What off-the-shelf software cannot do for a merchant portfolio is track deadlines that differ by reason code, record type, and rule, because it was never built to know those differences exist. A generic CRM has one SLA field. A payments business needs dozens, each tied to a specific requirement that a general-purpose tool was never designed to represent.

This shows up first and most expensively in dispute management. Visa’s Core Rules set a distinct dispute time limit for nearly every dispute condition, measured from a specific triggering date, not a single generic clock. Dispute Condition 11.2, Declined Authorization, carries a 75 calendar day limit from the transaction processing date. Dispute Condition 10.4, Other Fraud in a Card-Absent Environment, and Dispute Condition 12.5, Incorrect Amount, each carry a 120 calendar day limit, also measured from the transaction processing date, though in the case of an incorrect amount, from one of two possible triggering events. These are not three variations on a theme. They are three separate rules, with separate deadlines, that have to be tracked separately and correctly for every dispute a portfolio processes.

Why a generic SLA field cannot represent this

A CRM or support ticketing platform built for general business use has a due date field, maybe a priority tier, and a default SLA policy applied uniformly across cases. That model works fine for a support queue where every ticket is roughly the same kind of thing. It breaks the moment an ISO tries to use it to track dispute deadlines, because a dispute is not one kind of thing. It is dozens of distinct conditions, each carrying its own deadline, its own required documentation, and its own triggering date, defined not by the business but by Visa’s own rulebook.

Forcing that structure into a generic tool usually produces one of two outcomes. A team builds an elaborate workaround, custom fields, naming conventions, and spreadsheet cross-references layered on top of software that was never designed to hold this data, creating a fragile system that depends on someone remembering the workaround correctly every time. Or, more commonly, the team picks one conservative default deadline and applies it to everything, which either creates unnecessary rush on disputes that actually had more time, or far worse, lets the clock run out on a dispute whose real deadline was shorter than the default assumed.

The recordkeeping gap that nobody notices until an audit asks

A second, quieter version of the same problem sits in how long records actually have to be kept. FinCEN’s BSA recordkeeping rule, codified at 31 CFR 1010.430, requires covered financial institutions to retain records of certain financial transactions for five years. That is a specific, legally mandated floor, not a suggested best practice a business can round down from if storage costs matter.

Most off-the-shelf software was not built around that number. Its default retention and auto-purge settings are typically tuned for ordinary business convenience, often twelve to twenty-four months, because that is the right default for customer support tickets or sales records, the use cases the tool was actually designed for. A payments business that adopts one of these tools without explicitly reconfiguring retention, record type by record type, to match the BSA’s five-year floor is not making a deliberate risk decision. It is inheriting a default that was never evaluated against the rule that actually governs the data.

This gap is specifically dangerous because it is invisible day to day. A support ticket system that auto-purges records after eighteen months looks and functions identically to one that retains them correctly, right up until an examiner, a card network inquiry, or a legal dispute asks for a transaction record from three years ago and the business discovers it no longer exists.

A concrete example: the deadline that looked fine until it was not

Picture an ISO running disputes through a general-purpose ticketing tool, with a single default SLA of 90 days applied to every dispute ticket because that seemed like a reasonable middle ground across the cases the team had seen so far. A declined authorization dispute comes in. Under Visa’s actual rule, that dispute carries a 75 calendar day limit, not 90. Nobody built the ticketing tool to know that distinction exists, so the ticket sits in queue showing 90 days of runway that never actually existed.

By the time anyone notices the ticket is overdue, the real deadline passed two weeks earlier. The dispute response window has closed, not because anyone was careless, but because the software’s one-size-fits-all SLA field was never capable of representing a limit that Visa’s own rules set differently for this specific dispute condition. The same tool would have handled a 120 day dispute condition with time to spare, which is exactly the trap: the generic default feels safe most of the time and fails silently on the subset of cases where the real deadline runs shorter than the assumption built into the tool.

The deeper issue is the data model, not a missing checkbox

Neither of these gaps gets fixed by finding a slightly better off-the-shelf tool with one more configuration option. The real problem is structural. A generic CRM, ticketing system, or document management platform is built around generic concepts: a case, a ticket, a document, a customer record. It has no native concept of a Visa dispute condition with its own deadline logic, no native concept of an interchange qualification category that determines part of a residual calculation, and no native concept of a BSA-defined retention class that differs by record type rather than applying one policy to everything in the system.

Every one of those concepts is specific to this industry’s rulebook, and none of them map cleanly onto the generic objects a horizontal software product was designed around. A team can configure a generic tool extensively and still never get it to represent “this dispute’s deadline is 75 days from the transaction processing date because it is a declined authorization dispute, not 120 days because it is something else.” That distinction either lives in the software’s actual data model, enforced automatically, or it lives in a person’s memory, enforced inconsistently.

Where custom development actually earns its cost

This is exactly the calculation that should drive a build versus buy decision, and it cuts the opposite direction from how most teams default. Generic business functions, email, basic scheduling, standard accounting, are rarely worth building custom, because off-the-shelf tools handle generic problems well and custom development there mostly reinvents a solved wheel. The calculation flips entirely once the problem is specific to this industry’s own rules.

A dispute management system that encodes each dispute condition’s actual deadline and triggering date, rather than a single generic SLA, pays for itself the first time it prevents a dispute from timing out silently. A record retention system that applies the BSA’s five-year floor automatically by record type, rather than depending on someone remembering to configure it correctly, pays for itself the first time a record is needed years after a generic tool’s default settings would have deleted it. A residual reconciliation system that models interchange qualification categories directly, rather than treating every transaction as the same generic line item, catches the kind of downgrade-driven variance that a real residual audit has to go looking for manually when the underlying system was never built to track it in the first place.

What this means for how a growing portfolio should actually build

The practical takeaway is not that off-the-shelf software is always wrong. It is that the decision of what to build custom should be driven by where the industry’s own rules get specific, not by a general preference for buying over building. Dispute deadlines, retention schedules tied to specific record types, and reconciliation logic mapped to the card network’s own interchange categories are exactly the places where a generic tool’s data model cannot represent what the business actually needs tracked, no matter how much configuration gets layered on top.

A useful way to test this before committing to either path: list the specific rules a given workflow actually has to enforce. Then check whether the candidate off-the-shelf tool has a native field or object for each one. A dispute workflow needs a field for the specific dispute condition, not a generic category, because the condition is what determines the real deadline. A retention workflow needs a field for record type, not a single global setting, because the BSA’s five-year floor applies differently depending on what the record actually is. A tool that only offers a generic equivalent is not a close substitute waiting for configuration. It is missing the concept entirely. Configuration cannot invent a concept that was never built into the software’s underlying model in the first place.

Building that layer correctly is the core work of application development done for this industry specifically, not a generic software build. The data underneath it, dispute outcomes by reason code, retention status by record type, residual variance by interchange category, is exactly what a focused data and analytics engineering practice should be structured to expose, so the business can actually query and act on it rather than hoping a workaround spreadsheet stays current. And because these systems are the ones a regulator, a card network, or an acquirer’s own audit will eventually test directly, the quality assurance and continuous delivery discipline around them has to verify the specific rule, not just the generic feature, before anything ships.

Frequently Asked Questions

Why can’t a generic CRM or ticketing tool track chargeback deadlines correctly?

Visa’s dispute rules assign a different time limit to each dispute condition. A declined authorization dispute carries a 75 calendar day limit, while other fraud and incorrect amount disputes carry 120 calendar days, among many other conditions with their own specific limits. A generic tool’s single SLA or due-date field has no way to represent dozens of different deadlines keyed to the specific reason code and triggering date, so teams either build a workaround or silently default to the wrong deadline.

How long do payment records actually have to be kept under federal law?

FinCEN’s BSA recordkeeping rule at 31 CFR 1010.430 requires covered financial institutions to retain records of certain financial transactions for five years. A generic software tool’s default data retention or auto-purge settings are usually shorter than that and have to be explicitly reconfigured, record type by record type, to actually meet the floor.

What does custom software actually buy a growing ISO or payments platform?

A data model built around the industry’s own categories: dispute conditions with their own deadlines, interchange qualification tiers, and retention classes tied to the specific BSA or card network requirement that applies to each record type. Off-the-shelf tools model generic cases, tickets, and documents, which forces a team to either bolt on workarounds or quietly let the gaps go unmanaged.

Sources: Visa Core Rules and Visa Product and Service Rules, Sections 11.7.5.4, 11.8.2.4, and 11.9.4.4, and FinCEN, BSA Recordkeeping Requirements (31 CFR 1010.430).