Operating the Platform

A payments platform that's been built is not yet a platform that runs. Every day someone has to answer a merchant who can't find a payout, catch a file that didn't arrive, notice an issuer quietly declining more, file the reports the law requires, and know exactly what to do if card data ever leaks. This chapter is the operating layer: the tools and routines the rest of the volume assumes someone has. The general practice is in Observability, SLOs, On-Call, Incident Response and Disaster Recovery; what follows is what payments adds.

The Internal Console#

Support, risk and finance teams need a tool that sees what the platform sees, with controls the merchant-facing product doesn't have:

• Find anything by any identifier. A merchant quotes a payout amount, a cardholder quotes the acquirer reference number (ARN) their bank gave them, the processor quotes its reference, the bank quotes an ACH trace number. The console finds the payment, refund, payout or return from any of them, and shows its full history across systems (Inside a Processor).
• See as the merchant, on the record. Viewing a merchant's dashboard as they see it is how support answers questions, and it's an access to their data: it requires a reason, it's logged, and it's read-only unless an action is approved separately.
• Act on their behalf with approval. Refunds, holds and releases, payout pauses, reserve changes: each is a recorded action with an actor, a reason and, above a threshold, a second approver.
• Adjust the ledger only by entries. A manual adjustment is a ledger transaction with a reason code and a second approver, never an edit to a balance (Payment States & Ledgers). Adjustments get their own report, reviewed by someone outside support.
• Scope access by role. Support sees masked data; only the roles Running a Card Vault allows can reveal a card number, and nobody can approve their own action.

Watching the Pipeline#

Money movement fails quietly. A job that didn't run throws no errors; it just leaves payments that never left, and the first alert is a customer asking where their money is. So the monitoring watches for absence as carefully as for failure, and every alarm is tied to the deadline that makes it urgent, usually a bank cutoff.

• Captured but not sent. Payments still waiting to be batched as the cutoff approaches, per rail: ACH entries, check images for a deposit, card captures and refunds for the day's settlement batch.
• A file that should exist and doesn't. An outbound file not built or not transmitted, and an inbound one that didn't arrive. Returns, acknowledgements and settlement reports come every banking day, even empty; a missing return file doesn't mean there were no returns.
• Received but not applied. A file that arrived but didn't parse, or parsed but whose returns and notifications of change never reached the ledger.
• Over the limit. Your bank caps how much you may originate (for ACH, Nacha makes the ODFI set and monitor exposure limits), and you set a limit per merchant underneath it. Alarm while there's time to act, because the bank will hold or reject a file that breaches it.
• Overdue. A payment past its expected settlement date with neither a settlement nor a return. Silence isn't success: the ACH states advance on the clock, so a payment the bank never received would otherwise turn available on schedule.
• Money that should have moved. A sweep or prefunding transfer not confirmed by the cutoff, and reconciliation breaks by count and age, since a break stops payouts.
• Not ready for the bank. Check images missing an endorsement or a detail record before a deposit file goes out.
• Slow or failed jobs, and a job still running when the next one is due to start.
• Things that expire. TLS and network certificates, HSM and working keys, processor credentials, and the dates of network releases and account-range file loads are all quiet outages with a known date (HSMs & Key Management, Network Certification); alarm weeks ahead, not on the day.
• The monitor itself. If the alarms go quiet, is everything fine or did the monitor die? It sends a heartbeat on every run, and something outside it pages when the heartbeat stops.

Run the checks on the banking calendar, so a quiet weekend doesn't page anyone and a quiet Tuesday does. Observability covers the alerting machinery; these are the questions it should be asking.

Watching Approval Rates and Latency#

The pipeline alarms above catch money that didn't move. The other quiet failure is money that should have moved and was declined: an issuer tightens its fraud rules, a processor mislabels a field after a release, a BIN range starts failing, and approvals drop a few points without a single error.

• Approval rate, sliced. By processor, card brand, issuer or BIN range, card type, country, merchant category and channel, compared with the same slice's own history. A drop in one slice is a signal a platform-wide average hides (Processor Routing).
• Decline code mix. A rise in one code (do not honor, invalid transaction, issuer unavailable) usually names the cause before anyone investigates.
• Authorization latency, measured per hop against the networks' clocks, with an SLO well inside the 15-second timeout floor Visa sets for merchants.
• Webhook delivery: success rate, lag and backlog per merchant endpoint, because a merchant whose endpoint is failing is a merchant who thinks payments stopped (Webhooks).
• A status page merchants can read, fed by the same signals, so an incident is announced before the support queue announces it.

Statements and Reports#

Merchants reconcile against what you send them, so statements are part of the product:

• A monthly statement showing gross volume, refunds, disputes, every fee by type, payouts and the resulting balance. For interchange-plus pricing it separates interchange, network fees and markup, and shows the effective rate. Canada's Code of Conduct requires statements at least monthly with the effective rate per card type, interchange and network fees, and transaction counts and volumes (Payments in Canada); no federal rule sets US statement content, but merchants expect the same.
• Reports on demand, as asynchronous jobs that produce files, with the payout reconciliation report, every transaction behind every payout, as the one merchants use most (Designing the Payments API).
• Tax forms on schedule. 1099-Ks for every merchant, from the same ledger (Payments for Software Platforms).

Every number on a statement comes from ledger entries, never a separate calculation, so the statement, the reports and the payouts can't disagree.

Compliance Operations#

The obligations in The Payments Rulebook and Becoming a Payment Provider become daily work:

• Transaction monitoring for money laundering. Rules and models that look for laundering patterns in payments: a merchant whose volume or ticket size changes abruptly, refunds to cards that never paid, structuring around reporting thresholds, and funnel accounts, which FinCEN describes as an account in one place receiving many cash deposits, often below reporting thresholds, withdrawn somewhere else soon after.
• Transaction laundering. A merchant processing payments for another business it doesn't disclose, often one that couldn't get a merchant account itself. Visa's rules ban presenting transactions that don't come from a sale between the cardholder and that merchant, and both Visa's and Mastercard's merchant integrity programs fine acquirers for it, so merchant monitoring has to compare what's sold with what was underwritten (Fraud & Risk).
• Suspicious activity reports on the clock. A bank files within 30 days of first detecting suspicious activity, extendable by 30 more only to identify a suspect and never beyond 60; a money services business files within 30 days, at a $2,000 threshold. Reports and their supporting records are kept five years.
• Sanctions screening that never stops, on merchants, their owners, and payouts, against lists that change daily.
• Case management. Every alert becomes a case with an owner, a decision and a record of why, because an examiner will ask about the alerts you closed, not only the reports you filed.

When Card Data Is Exposed#

The incident every provider plans for and hopes never to run. The general shape is in Incident Response; card data adds deadlines set by the networks:

• Tell the networks fast. Visa's What To Do If Compromised guide (version 10.0, June 2026) requires reporting to Visa within three calendar days of evidence that suggests or confirms a compromise, an incident report within three days of that notice, and the at-risk account numbers within three days as well. Mastercard's account data compromise rules are stricter: notify Mastercard within 24 hours of becoming aware of an actual or potential compromise, identify and preserve evidence within 24 hours, and provide the affected account numbers within 72 hours. Whichever brand's clock is shortest sets yours.
• A forensic investigator, if required. When Visa requires one, the entity contracts a PCI Forensic Investigator within five business days, the investigator's preliminary report is due within five business days of being retained, and the final report within ten business days of the investigation's end. The investigator can't be affiliated with you or have provided you services (as your assessor or advisor, for example) recently.
• Preserve before you fix. Don't power off or rebuild affected systems; isolate them and keep the logs and images, because the investigation depends on them.
• The rest of the law. Every US state, the District of Columbia and several territories have breach notification laws, with deadlines that differ by state, and merchants on your platform have their own obligations to their customers.
• Have the plan ready. PCI DSS requires an incident response plan that includes notifying the brands and acquirers, tested at least every 12 months, with people available around the clock (12.10.1 to 12.10.3), and a procedure for card numbers found where they shouldn't be (12.10.7).

How Long to Keep What#

A payments platform keeps records for many rules at once, and each record's retention is the longest any rule requires, then deletion:

Record	Keep for	Why
Card numbers	Only as long as your documented business need, verified quarterly	PCI DSS 3.2.1 (Running a Card Vault)
Security audit logs	At least 12 months, the latest 3 months immediately available	PCI DSS 10.5.1
Anti-money-laundering records and suspicious activity reports	5 years	Bank Secrecy Act
ACH authorizations	2 years after the authorization ends	Nacha (ACH & Bank Transfers)
Electronic fund transfer and check records	At least 2 years	Regulation E, Regulation CC
Information returns (1099s)	3 years, or 4 with backup withholding	IRS
Tax and business records	3 years by default, longer in specific cases	IRS
Dispute evidence	At least the longest dispute window that could reach the payment	Network dispute rules
Call recordings with payment data	Never containing a card verification code	Phone Payments

Where rules collide, the longest wins and deletion is a scheduled job, not a judgment call; Data Retention & Deletion covers how deletion coexists with append-only ledgers.

Complaints and Error Resolution#

Sponsor banks and regulators expect a complaint process, and consumer law sets clocks on some of it. Log every complaint with a category, owner and outcome, so patterns surface and the bank's reports write themselves. For consumer bank debits, Regulation E's error resolution applies: a consumer has 60 days after their statement to report an error, and the institution investigates within 10 business days, or 45 with provisional credit (ACH & Bank Transfers). Card complaints usually become disputes, which have their own process; everything else (a fee a merchant doesn't recognize, a payout they think is missing) needs a deadline of your own, published and kept.

Closing the Books#

The platform's own finances run on the same ledger. Each month, finance closes: every processor and network invoice reconciled against the fees the ledger expected, the platform's revenue recognized from ledger entries rather than from bank deposits, reserves and negative balances valued, and the custodial cash equation tied out on the last day. Enterprise merchants and partners will ask for a SOC 1 report on the controls behind these numbers, separate from the security-focused SOC 2.

Offboarding a Merchant#

Merchants leave or are terminated, and both are processes, not deletes. Stop new payments, keep refunds and disputes flowing, hold a reserve through the dispute tail of what was sold (120 days and more for goods delivered later), then pay out the remainder after a final reconciliation. A merchant terminated for cause may need to be reported to the networks' terminated-merchant lists (Inside a Processor), a merchant whose bank account no longer works leaves a balance that eventually becomes unclaimed property (Payouts & Settlement), and the records stay for the retention periods above. Moving a merchant to another provider means exporting its stored cards to a PCI-compliant recipient on request (Processor Routing).

When a Region Fails#

Disaster Recovery covers the general practice; payments adds specifics. Authorization needs the shortest recovery time, since every minute down is sales lost; payouts and file processing can wait hours. The vault's keys and the HSMs must be recoverable in the other region without ever existing in the clear, which means key backups made under the same dual control as everything else (HSMs & Key Management). And after a failover, every bank file and every unsettled payment is checked against what the bank and processor actually received before anything is resent, because a duplicated file is a duplicated payment (Treasury & Bank Operations).

What This Means for the System You Build#

• An internal console that finds anything by any identifier, acts only with recorded reasons and approvals, and adjusts the ledger only by entries.
• Pipeline alarms for absence, a heartbeat on the monitor, all on the banking calendar.
• Approval rates sliced by processor, issuer and BIN, decline code mix, latency against the networks' clocks, and webhook health, with a public status page.
• Monthly statements and reports from the ledger, so nothing a merchant sees can disagree with anything else.
• Compliance operations as casework: monitoring, reports on deadline, screening that never stops.
• A card-data incident plan with the networks' deadlines in it, rehearsed yearly.
• A retention schedule that takes the longest rule for each record, and deletes on schedule.

References#

Specifications

• Visa: What To Do If Compromised (PDF), reporting within three days, forensic investigation timelines and evidence preservation (version 10.0)
• 31 CFR 1020.320, suspicious activity reports by banks: 30 days, at most 60
• 31 CFR 1022.320, suspicious activity reports by money services businesses: $2,000 and 30 days
• 31 CFR 1010.430, five-year retention of Bank Secrecy Act records
• 12 CFR 229.21, Regulation CC record retention
• Mastercard: Security Rules and Procedures, Merchant Edition, August 2026 (archived PDF), account data compromise notification, preservation and card number deadlines (10.3.1)
• 12 CFR 1005.11, Regulation E error resolution timeframes

Reference

• FinCEN: Advisory on funnel accounts (FIN-2014-A005), the funnel account pattern
• Visa Core Rules and Visa Product and Service Rules, anti-money-laundering programs and the ban on laundering transactions (1.9.1, 5.2.1.6)
• NCSL: Security breach notification laws, laws in every state, DC and the territories
• FCAC: Code of Conduct for the Payment Card Industry in Canada, monthly statement contents
• IRS: How long should I keep records?, default and extended retention periods
• IRS: Publication 1099, retention of information return copies
• Nacha: Why exposure limits are so important, ODFI exposure limits and monitoring

In practice

• LegitScript: BRAM and VIRP basics (PDF), the networks' merchant integrity programs and acquirer fines