TL;DR: This is the known "slow accept" bug Quicken has acknowledged (Ticket# 12451736 / CTP-17391, "Slow Acceptance of transactions," escalated 6/9/26, still open as of 6/23/26 with no ETA). I'm affected and ran a Process Monitor trace that pinpoints the likely mechanism: every time you "Accept" a downloaded transaction in Compare-to-Register (C2R) mode, Quicken appears to get stuck in a tight loop repeatedly opening, locking, and closing its own config file (QUICKEN.INI) — roughly 2,000 times per second — adding about a 1-second delay per transaction. The actual write to your data file is fast; the delay is something else. Posting the trace data here in case it helps Quicken's engineering team, or other affected users.
Symptoms
- Accepting downloaded transactions takes ~1-2 seconds each, with a visible per-transaction processing delay (you can watch it grind through one at a time)
- A couple of months ago, accepting a batch of 20+ transactions took well under a second total — this is a clear regression, not how Quicken has always behaved
- Affects all account types (banking, credit card) — not isolated to one institution or account
- Matches Quicken's own known-issue description: occurs specifically in Compare to Register (C2R) mode, i.e. automatic entry turned off, where you manually match/accept downloaded transactions against the register rather than having them auto-post
Environment
- Windows, Version 27, R67
- Windows 11, all-SSD storage
- Data file ~145MB, stored in a OneDrive-synced folder set to "Always keep on this device"
What I ruled out (no effect on the slowdown)
- File → Validate and Repair
- Reduced Memorized Payee List by more than half
- Mobile/Web Sync — already disabled
- Antivirus and firewall (including Acronis) — temporarily disabled, no change
- OneDrive sync — paused entirely, no change
- iCloud — closed, no change
- No scheduled reminders/bills configured
- Task Manager during slow accepts: ~5% CPU only, no significant disk spike, network/Ethernet activity flat — ruling out compute-bound, disk-bound, and network-bound explanations
What Process Monitor actually showed
I captured a ProcMon trace filtered to qw.exe during a batch of accepts (~58 second window):
- Total busy duration across all 248,019 logged operations: only ~2.25 seconds. Over 96% of the wall-clock time isn't accounted for by any single logged file/registry operation — meaning this isn't heavy disk I/O or computation, it's time spent in a wait/loop state.
- The dominant activity by far is repeated access to
C:\ProgramData\Quicken\Config\QUICKEN.INI — 111,447 operations, about 45% of everything in the trace. It's a clean repeating cycle: CreateFile → ReadFile → CloseFile → QueryStandardInformationFile → QueryEAFile → LockFile → UnlockFileSingle, each occurring 15,921 times, every single one returning SUCCESS. - This cycle runs at a sustained rate of ~2,000 events/second, pulsing roughly every 7 seconds throughout the capture.
- By contrast, the actual writes to my QDF data file are fast and unremarkable — a clean burst of ~30-40 small
WriteFile operations completing in well under 1ms total, per accept. - There's a clear gap between QDF write bursts (e.g., one burst completes, the next doesn't start until roughly 1.5 seconds later) — and the QUICKEN.INI thrashing fills that gap.
- Secondary, smaller-scale activity follows a similar periodic pattern against
FeatureFeedback\local.settings (328 events) and FeatureEnablement.ini (5,460 events). - QUICKEN.INI itself is only 3KB, with no corruption or unusual content — the access volume looks behavioral (a loop), not something caused by file size or content.
My (non-developer) read on this
Something introduced in R67 appears to re-check a setting in QUICKEN.INI once per transaction accept when in C2R mode — possibly tied to the [AFS] section's license/feature-entitlement keys (CheckAlertsUntil, MondoUntil) or the periodic-update keys (Periodic_update_period, Periodic_last_update) — and does so via a tight open/lock/unlock/close loop rather than a cached read, adding roughly a second of overhead per transaction. That would explain why it's specific to C2R/manual-accept mode (per Quicken's own known-issue description) and why disabling sync/AV/cloud storage has no effect — the bottleneck is internal to the application, not the surrounding environment.
Attached: a redacted, trimmed ProcMon export (~340 rows) showing a representative slice of the pattern described above — an early QDF write burst followed by a chunk of the QUICKEN.INI cycle, full original timestamp precision preserved, personal file paths/username redacted. Happy to share more of the full capture if useful.
If you're hitting this too, worth checking whether you're also in C2R/manual-entry mode — that seems to be the common thread across reports. Quicken folks — feel free to attach this to CTP-17391 if it's useful; happy to provide more detail or run additional traces if it'd help narrow this down further.
Unfortunately the forum does not allow uplods of xlsx or csv files - so converted to a PDF (not as good for reading - but it is what it is).
