ACI–Cognizant AWS Test: What Payment Teams Must Prove Before Production

ACI Worldwide and Cognizant have supplied a useful but deliberately bounded data point for payment operators: a non-production performance test of BASE24-eps on Amazon Web Services sustained more than twice its target transaction load for 30 minutes without a failed transaction. Across the full exercise, the platform processed more than 4.6 million transactions without failure. The result is evidence about one simulated test, not a production availability claim.

The test used Amazon EC2, Amazon RDS for PostgreSQL, OpenTelemetry, and Amazon CloudWatch. That stack makes the exercise relevant to teams considering cloud infrastructure for card processing because it shows the processing component alongside database and monitoring services. It does not, on its own, show that a bank or processor can reproduce the same result with its own network connections, transaction mix, security boundary, operational staffing, or control requirements.

The first discipline is to preserve the status of the evidence. A vendor-sponsored test can be valuable when its method and boundaries are clear, but it is not an independent certification and it is not a production go-live. The reported no-failed-transaction result belongs to a simulated, non-production environment. It should enter a diligence pack as a verified test observation, with the workload definition and test artefacts attached, rather than as a promise to customers or a forecast of live performance.

Payment teams should begin by rebuilding the workload faithfully. The site-find brief asks whether the test reproduces transaction types, concurrency, latency targets, and failure conditions in the real estate. That means mapping authorisations, reversals, declines, timeouts, retries, duplicate messages, settlement-related events, and any other material flow before a benchmark is accepted. A single aggregate transaction count can hide very different processing paths and operational risks.

Workload fidelity also requires a credible traffic shape. Operators should record arrival rates, concurrency, payload sizes, connection behaviour, database reads and writes, partner calls, and the order in which events occur. Peak load should be tested beside normal load, ramp-up, ramp-down, burst behaviour, and sustained duration. If synthetic traffic omits slow dependencies or exception-heavy paths, the test may measure an efficient laboratory route rather than the system that customers will actually use.

The reported headroom is therefore a starting point for a capacity argument. More than twice target load for 30 minutes is a meaningful simulated result, but the target itself needs an owner, a source, and a link to the production forecast. Teams should define the permitted latency distribution, error budget, queue depth, resource saturation, and recovery behaviour at each traffic level. They should also repeat the test after configuration changes instead of treating one successful run as a permanent capacity certificate.

Observability must be tested as part of the payment path, not added after it. OpenTelemetry and CloudWatch were instrumented in the reported exercise, giving operators named tools for traces, metrics, logs, and infrastructure signals. Before cutover, the team should prove that a transaction can be followed across ingress, processing, database activity, partner response, exception handling, and reconciliation. Alerts need thresholds, owners, escalation routes, retention rules, and a way to distinguish a customer-visible failure from a noisy but harmless infrastructure event.

The evidence does not establish a latency distribution. Average response time would not answer whether a small but material tail of transactions becomes slow during contention, retries, database pressure, or dependency failure. Operators should capture p50, p95, p99 and maximum latency by transaction type, together with timeout and retry counts. Unknown latency is not a minor reporting gap for card processing: it can affect customer experience, duplicate risk, queue growth, and the time available for an operator to intervene.

Resilience is the next gate. The site-find contract specifically calls for multi-availability-zone resilience, failover, and disaster recovery before production readiness is claimed. A load test that continues without failure in one non-production run does not demonstrate what happens when an instance, database node, availability zone, network path, credential, or external dependency is unavailable. Each failure exercise should define the injected fault, expected detection time, traffic treatment, data outcome, recovery objective, and evidence that the service returned to a controlled state.

Disaster recovery should be demonstrated separately from high availability. Teams need a documented recovery point objective and recovery time objective for the relevant payment records, along with restoration tests that include ordering, idempotency, replay, and reconciliation. A restored service that accepts traffic but cannot explain which messages were committed, rejected, or duplicated is not recovered in an operational sense. The runbook should identify decision owners, communication paths, partner notifications, and the conditions for returning to the primary path.

Reconciliation is a production control, not an accounting afterthought. For every test and later pilot, operators should compare messages entering the system, decisions produced, records written, partner acknowledgements, reversals, and settlement or ledger outputs. Breaks need a queue, severity, owner, ageing target, and evidence of resolution. The reported transaction total and no-failed-transaction result do not establish reconciliation accuracy, because the source does not disclose the test's ledger design, exception treatment, or independent comparison process.

Certification and security create additional gates. Payment-network certification must be completed for the applicable flows before live traffic is permitted, and certification evidence should be tied to the exact software, configuration, message versions, and operational procedures that will run in production. Hardening should cover identity, secrets, network segmentation, encryption, privileged access, patching, vulnerability handling, logging, and change approval. The source calls out hardening and certification as prerequisites; it does not establish that those prerequisites have been completed.

Fraud and compliance outcomes remain unknown. The performance test does not disclose fraud-control effectiveness, false positives, sanctions or screening behaviour, privacy controls, regulatory mapping, or audit readiness. A faster authorisation path can still be unsuitable if controls are bypassed, if investigators cannot reconstruct decisions, or if data handling falls outside an approved boundary. Security and compliance teams should run their own scenarios, retain evidence, and document which controls are inherited from the cloud environment and which remain the operator's responsibility.

Cost and regional design also need evidence before a business case is approved. The source does not disclose transaction economics, compute and database consumption, observability charges, network transfer, support staffing, licensing, or the cost of redundancy. It also does not specify the regions or multi-region architecture used. Finance and platform teams should model normal, peak, failover, recovery, and idle capacity cases, then compare those costs with the current operating baseline. Cloud scale is not automatically a lower-cost operating model.

A controlled path to production should use decision gates rather than a single approval meeting. Gate one confirms workload fidelity and baseline measurements. Gate two confirms observability, security hardening, and test evidence. Gate three passes availability-zone failure, disaster recovery, reconciliation, and partner recovery scenarios. Gate four verifies certification, fraud and compliance sign-off, cost limits, runbooks, staffing, and rollback readiness. Only then should a limited pilot begin, with explicit traffic ceilings and an owner authorised to stop it.

Rollback must be a tested operating action, not a sentence in a migration plan. Teams should define the trigger thresholds for latency, failure, reconciliation breaks, fraud-control anomalies, cost overruns, or partner instability. They should know whether rollback means routing traffic to the prior processor, pausing a flow, draining queues, or placing transactions into a controlled exception path. The procedure must protect idempotency and customer communication while preserving a complete audit trail. A pilot should expand only when the measured evidence remains within approved thresholds over an agreed observation period.

The ACI–Cognizant result is best used as a prompt for this work. It shows that BASE24-eps processed a large simulated volume without a failed transaction and sustained more than twice target load for 30 minutes in the reported environment. It does not answer how the platform behaves under a real transaction mix, live dependencies, regional failure, fraud pressure, certification review, or production economics. Payment teams can move forward responsibly by converting the result into reproducible tests, named controls, explicit owners, and gates that can still say no.

Published September 29, 2026 · Source event September 28, 2026