Predictika · Payments platform orders

An AI sales agent's payments platform order, checked before it goes out

An AI sales agent prepares an order for a payments switching platform: the processing modules, the platform it runs on, the edition, the support level, and the peak load, card base and regions the customer expects. Before the order goes out, the agent sends it to Predictika, which checks it against a declarative model of what each edition and module allows and returns a verdict and every reason.

Scope: ACI BASE24-eps payments platform orders: ACI Issuer, Acquirer, Interchange, Fraud Management, Money Transfer System, EMV key management, NDC interface, migration tools, platform, edition, support and stated peak-load limit. See everything this validator covers

This validator models payments platform orders for these products, not just the scenarios shown below.

  • Modules — an order needs at least one of ACI Issuer, ACI Acquirer or ACI Interchange, EMV key management needs Issuer or Acquirer, and the NCR NDC interface needs Acquirer.
  • Platforms — ACI Money Transfer System is ordered on IBM Power, ACI Fraud Management on IBM Z or as a managed service, and the BASE24 migration tools are not ordered on Red Hat Linux.
  • Editions — Regional, National and Global editions each take a modeled peak load, card base and number of regional components.
  • Support — a managed service is ordered with Extended or Premier support, and the Global edition with Premier support.
  • Approvals and stated limits — a Global edition order, more than five regional components and a very high peak load go to a person, and a peak-load limit stated on the order is compared with the edition.

Any payments platform order that touches these rules is in scope — not only the scenarios pictured here. Not covered: other ACI products and prices, which this validator does not model. The product names, platforms and delivery options follow public ACI pages. The editions, their limits, the dependencies, support requirements and approval thresholds are modeled from comparable payment-switch products, are illustrative and are not published by ACI.

The AI sales agentBuilds the platform order from the conversation with the customer and says it is ready.
Predictika validatorChecks every rule at once and returns the verdict, each finding, and the computed figures.

7 scenarios in 3 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

The AI sales agent says

Illustrative agent statement. The validator receives the structured request below.

Proposing agent: AI sales agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      
Waiting for the call.

Where rules-based CPQ gets it wrong

Click to expand

Our assessment of what a typical rules-based CPQ (product rules, price rules and validation rules, as in Salesforce CPQ) does with the same cases. It is a judgment about effort and reliability, not a claim that nothing can be built.

What the validator caughtTypical rules-based CPQPredictika
Modules that depend on each otherOnly with care
EMV key management and the NDC interface each need another module on the same order, so a rule per dependency is needed and is easy to miss when a module is added.
Every dependency is checked in the same pass as every other rule.
Modules that belong to one platformOnly with care
Money Transfer System, Fraud Management and the migration tools each run on some platforms and not others, so the product rules must be kept in step with the platform choice.
The platform is compared with every module on each call.
Limits that depend on the editionOnly with workarounds
Peak load, card base and regions each have a limit that changes with the edition, so separate rules or tables are needed and are easy to leave out for a new edition.
The edition limits are computed inside the model and compared with the order on every call.
A stated limit reconciled with the editionOnly with workarounds
The limit the order states has to be compared with the limit the edition really has, which needs a separate calculation.
The stated limit is compared with the computed one on every call.
Support that depends on the platform and editionOnly with care
A managed service and the Global edition each need a higher support level, and the rules interact with each other.
These requirements are checked together with the other rules.
Every problem returned in one answerOnly with workarounds
Rules tend to fire as the order is saved or a step is completed, so a person often fixes one error and meets the next.
All findings come back together, whatever order the choices arrived in.

What this validator catches: findings from its test cases

Click to expand

Every rule is checked on every call, in any order the choices arrive; one problem never hides another. Blocking findings stop the order; approval findings need a person to sign off; everything else is computed.

1The order has none of ACI Issuer, ACI Acquirer or ACI Interchange, so BASE24-eps has nothing to process.
2ACI Money Transfer System is ordered on IBM Power (AIX); this order uses another platform.
3ACI Fraud Management is modeled on IBM Z or as a managed service only.
4EMV key management needs ACI Issuer or ACI Acquirer on the same order.
5The NCR NDC message interface serves ATM acquiring and needs ACI Acquirer.
6The BASE24 to BASE24-eps migration tools are modeled for IBM Z, IBM Power and managed-service targets only.
7The Global edition is modeled on IBM Z, IBM Power or managed service, not on Red Hat Linux.
8A Global edition order is scoped with a person before it is released.
9A managed service is modeled with Extended or Premier support.
10The Global edition is modeled with Premier support only.
11201 peak transactions per second is over the 200 the edition takes.
126 million cards is over the 5 million the edition takes.
132 regional components is over the 1 the edition takes.
146 regional components need a localization review by a person.
155,001 peak transactions per second needs a capacity review by a person.
16The order states a limit of 200 transactions per second; this edition is modeled at 1,500.

Scenarios and results

Click to expand

The recorded result of the validator for each scenario on this page: the request the AI agent sent, the verdict, and every finding, in the order they appear above.

1. Fraud management and money transfer at a high load: Fraud Management and Money Transfer System on Red Hat Linux, with a peak of 2,000 transactions per second and 60 million cards

The agent's request. Please order BASE24-eps National edition with ACI Issuer, ACI Acquirer, ACI Fraud Management and ACI Money Transfer System, on Red Hat Linux with Extended support, for a peak of 2,000 transactions per second, 60 million cards and 1 region. It is ready to send.

Verdict: Blocked.

  • Money Transfer System off IBM Power. ACI Money Transfer System is ordered on IBM Power (AIX); this order uses another platform.
  • Fraud Management on Power or Linux. ACI Fraud Management is modeled on IBM Z or as a managed service only.
  • Peak load over the edition. 2,000 peak transactions per second is over the 1,500 the edition takes.
  • Card base over the edition. 60 million cards is over the 50 million the edition takes.

2. Fraud management and money transfer at a high load: The agent resubmits after fixing the errors

The agent's request. Please order BASE24-eps National edition with ACI Issuer, ACI Acquirer, ACI Fraud Management and ACI Money Transfer System, on IBM Z with Extended support, for a peak of 2,000 transactions per second, 60 million cards and 1 region. It is ready to send.

Verdict: Blocked.

  • Money Transfer System off IBM Power. ACI Money Transfer System is ordered on IBM Power (AIX); this order uses another platform.
  • Peak load over the edition. 2,000 peak transactions per second is over the 1,500 the edition takes.
  • Card base over the edition. 60 million cards is over the 50 million the edition takes.

3. Fraud management and money transfer at a high load: The agent resubmits after fixing the errors

The agent's request. Please order BASE24-eps National edition with ACI Issuer, ACI Acquirer and ACI Fraud Management, on IBM Z with Extended support, for a peak of 1,400 transactions per second, 45 million cards and 1 region. It is ready to send.

Verdict: Allowed.

  • Order summary. The edition takes up to 1,500 transactions per second, 50 million cards and 3 regions; this order has 1400, 45 and 1.

4. EMV keys and NDC interface on an interchange-only order: EMV key management and the NDC interface on an order with ACI Interchange only

The agent's request. Please order BASE24-eps National edition with ACI Interchange, EMV key management and the NCR NDC interface, on IBM Z with Extended support, for a peak of 100 transactions per second, 2 million cards and 1 region. It is ready to send.

Verdict: Blocked.

  • EMV key management without issuing or acquiring. EMV key management needs ACI Issuer or ACI Acquirer on the same order.
  • NDC interface without Acquirer. The NCR NDC message interface serves ATM acquiring and needs ACI Acquirer.

5. EMV keys and NDC interface on an interchange-only order: The agent resubmits after fixing the errors

The agent's request. Please order BASE24-eps National edition with ACI Acquirer, ACI Interchange, EMV key management and the NCR NDC interface, on IBM Z with Extended support, for a peak of 100 transactions per second, 2 million cards and 1 region. It is ready to send.

Verdict: Allowed.

  • Order summary. The edition takes up to 1,500 transactions per second, 50 million cards and 3 regions; this order has 100, 2 and 1.

6. Managed service on the Regional edition: Managed service on the Regional edition with Standard support

The agent's request. Please order BASE24-eps Regional edition with ACI Issuer and ACI Acquirer, on a managed service with Standard support, for a peak of 400 transactions per second, 3 million cards and 1 region. The order states a peak-load limit of 1,500 transactions per second for the edition. It is ready to send.

Verdict: Blocked.

  • Managed service on Standard support. A managed service is modeled with Extended or Premier support.
  • Peak load over the edition. 400 peak transactions per second is over the 200 the edition takes.
  • Stated peak-load limit does not match. The order states a limit of 1,500 transactions per second; this edition is modeled at 200.

7. Managed service on the Regional edition: The agent resubmits after fixing the errors

The agent's request. Please order BASE24-eps National edition with ACI Issuer and ACI Acquirer, on a managed service with Extended support, for a peak of 400 transactions per second, 3 million cards and 1 region. The order states a peak-load limit of 1,500 transactions per second for the edition. It is ready to send.

Verdict: Allowed.

  • Order summary. The edition takes up to 1,500 transactions per second, 50 million cards and 3 regions; this order has 400, 3 and 1.

Narration transcript

Click to expand

The text of the narrated walkthrough, step by step.

  1. Welcome to a demo of Predictika's Validator. An AI sales agent prepares an order for a payments switching platform: the processing modules, the platform it runs on, the edition, and more. Before the order goes out, the agent sends it to Predictika, which checks it against a declarative model of what each edition and module allows and returns a verdict and every reason.
  2. I will start with the first request by the agent.
  3. The agent says. Please order BASE24-eps National edition with ACI Issuer, ACI Acquirer, ACI Fraud Management and ACI Money Transfer System, on Red Hat Linux with Extended support. It is ready to send. The rest of the request is on screen.
  4. Before it goes out, the agent calls the validator.
  5. Blocked, with four findings, all in one answer. ACI Money Transfer System is ordered on IBM Power (AIX); this order uses another platform. ACI Fraud Management is modeled on IBM Z or as a managed service only. 2,000 peak transactions per second is over the 1,500 the edition takes. The other one is on screen.
  6. The validator returned four blocking findings in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the order are checked against each other.
  7. What this shows: for limits that depend on the edition, a rules-based CPQ can do this only with workarounds.
  8. Now the agent resubmits.
  9. The corrected request. It changes the platform to IBM Z.
  10. It calls the validator again.
  11. Still blocked, with three findings, all in one answer. ACI Money Transfer System is ordered on IBM Power (AIX); this order uses another platform. 2,000 peak transactions per second is over the 1,500 the edition takes. 60 million cards is over the 50 million the edition takes.
  12. One finding cleared. Still blocking: money Transfer System off IBM Power, peak load over the edition and card base over the edition.
  13. The agent resubmits once more.
  14. The revised request. It changes the modules to ACI Issuer, ACI Acquirer and ACI Fraud Management, the peak load to 1,400 and the cards to 45 million.
  15. It calls the validator once more.
  16. This time the validator clears it.
  17. All three earlier findings are cleared.
  18. Four problems caught in one call, fixed in two passes, and a clean order. That is the value of Predictika's validator: catching mistakes before they reach the customer. Now you can try the other scenarios yourself.