IndustryApproval, not just fraud
False declines cost more than fraud
Legitimate transactions declined by over-tuned rules routinely exceed the fraud losses those rules prevent, which reframes the optimisation entirely.
Program 03 · Domain specialisation
SCIKIQ Certified Data and AI EngineerCards & Payments
Payments is two systems wearing one name. One is a real-time path where an answer is required in well under a second and a model has no business being. The other is everything around it — disputes, merchant risk, reconciliation, scheme rules — which is document-heavy, slow and almost entirely manual. Knowing which is which is most of the engineering judgement here.
- 80 hrstaught
- 40hands-on AI labs
- 8assessment tests
- +20 hrs2 E2E capstones
PCI scopeCard data that must never reach a model, a log or a trace
Sub-secondThe authorisation path, where inference does not belong
Scheme rulesA rulebook corpus governing every dispute outcome
False declinesThe cost line that is larger than the fraud it prevents
01
Part 1 · The business
The value chain, the people, the trends
Money moves in milliseconds and the arguments about it take months. Part 1 maps both halves and names the people who work in each.
The payments value chain
Six stages from onboarding to interchange. Select one.
01
Onboard & underwrite
Merchant and cardholder onboarding, KYB and KYC, and the risk decision behind acceptance.
Decisions made here
- Do we board this merchant?
- What limits apply?
- What is the true business behind this application?
Where it breaks today
- Merchant category and business model taken at face value from the application
- Underwriting evidence assembled manually from public sources
- Transaction laundering discovered long after boarding
What is measured
- Approval rate
- Loss per boarded merchant
- Time to board
Where AI landsMerchant evidence assembly, business-model verification and portfolio anomaly review.
Approval rateLoss per boarded merchantTime to board
02
Authorise
Real-time authorisation, risk scoring, 3-D Secure and the accept-or-decline decision.
Decisions made here
- Approve or decline?
- Step up or let through?
- Is this the cardholder?
Where it breaks today
- False declines that cost more than the fraud they stopped
- Rules accumulated over years that nobody dares remove
- Decisions made in milliseconds with no room to reason
What is measured
- Approval rate
- Fraud basis points
- False decline rate
Where AI landsOffline rule mining and decline-reason explanation — not inline inference.
Approval rateFraud basis pointsFalse decline rate
03
Clear & settle
Clearing files, settlement, funding, fees and the reconciliation between them.
Decisions made here
- Does this reconcile?
- Where is the difference?
- When does the merchant get funded?
Where it breaks today
- Reconciliation breaks investigated across scheme file formats
- Fee calculations that nobody can fully explain
- Funding queries answered by a person reading files
What is measured
- Reconciliation break rate
- Funding accuracy
- Days to resolve
Where AI landsBreak diagnosis across clearing and settlement, and fee explanation.
Reconciliation break rateFunding accuracyDays to resolve
04
Dispute & chargeback
Disputes, chargebacks, representment, pre-arbitration and arbitration under scheme rules.
Decisions made here
- Is this dispute valid?
- Do we represent?
- What evidence does the rule require?
Where it breaks today
- Scheme rulebooks read by a handful of specialists
- Representment packs assembled by hand against a deadline
- Cases lost on evidence that existed but was not attached
What is measured
- Win rate
- Cost per dispute
- Cases within deadline
Where AI landsReason-code interpretation, evidence assembly and representment drafting.
Win rateCost per disputeCases within deadline
05
Manage fraud & risk
Fraud strategy, portfolio monitoring, chargeback thresholds and merchant exposure.
Decisions made here
- Where is the emerging pattern?
- Which merchant is drifting?
- Are we within scheme thresholds?
Where it breaks today
- Emerging fraud patterns found after the loss
- Analyst time consumed by triage rather than strategy
- Merchant drift visible only in a monthly report
What is measured
- Fraud basis points
- Chargeback ratio
- Detection lag
Where AI landsPattern discovery in cleared data, merchant drift detection and alert triage.
Fraud basis pointsChargeback ratioDetection lag
06
Scheme compliance & interchange
Scheme rule changes, interchange qualification, compliance programmes and reporting.
Decisions made here
- What changed in the rules?
- Are we qualifying correctly?
- What does this programme require?
Where it breaks today
- Rule bulletins arriving continuously and read late
- Interchange downgrades discovered in the invoice
- Compliance evidence assembled per programme by hand
What is measured
- Interchange qualification rate
- Rule changes actioned on time
- Programme status
Where AI landsRule-change impact analysis, downgrade diagnosis and compliance evidence assembly.
Interchange qualification rateRule changes actioned on timeProgramme status
Who you are building for
The fraud analyst and the disputes team are fighting the same losses from opposite ends. Select one to light the stages they own.
What the sector is seeing
A real-time business whose slow half is where the automation opportunity actually sits.
IndustryRules as language
Disputes are a rulebook problem
Outcomes turn on what the scheme rule requires for a given reason code, and that corpus is read fluently by very few people in any organisation.
IndustryOffline, not inline
Inference belongs off the authorisation path
The real-time decision has a latency budget a model cannot meet, so the value is in mining and explaining decisions offline rather than making them inline.
IndustryTokenise before reasoning
PCI scope shapes the architecture
Primary account numbers must not reach model context, logs or traces, which makes tokenisation and field scoping an architectural decision rather than a control.
IndustryBoarded is not verified
Merchant drift is the acquiring exposure
Businesses change what they sell after boarding, and the gap between stated and actual model is where acquiring losses concentrate.
IndustryNormalise, then reconcile
Reconciliation remains stubbornly manual
Clearing, settlement and funding are reconciled across formats that were never designed to agree, which is a normalisation problem before it is an analytics one.
02
Part 2 · Data and meaning
Domains, ontology, taxonomy and governed terms
The architecture has an unusual shape: a hot path you must stay off, and a cold estate where everything interesting lives. The first design decision is drawing that line and keeping card data on the correct side of it.
The data landscape
Six families. The first must be tokenised before it touches anything downstream.
Authorisation messages
Real-time request and response traffic, including card data.
ISO 8583 / ISO 20022 switchesClearing & settlement
Scheme clearing files, settlement positions, fees and funding.
Scheme files, settlement enginesMerchant & cardholder
Onboarding records, KYB and KYC evidence, limits and status.
Boarding systems, KYC platformsDisputes
Cases, reason codes, evidence, representments and outcomes.
Dispute management systemsScheme rules
Rulebooks, bulletins, compliance programmes and interchange tables.
Scheme publicationsFraud & risk
Scores, rule outcomes, case history and confirmed fraud markers.
Fraud platforms, case systemsThe semantic layer
A payments agent that cannot tell a cardholder from an account, or a dispute from a chargeback stage, will produce answers that are procedurally wrong even when they are factually right. These are the domains, the graph and the definitions it must be grounded on — and one entity it must never hold.
Data domains
Six subject areas, each with the entities it holds, its critical data elements and the function accountable for it.
Cardholder & account
Who is paying, and the credential they pay with.
CardholderAccountCard tokenDevice token
- Critical data elements
- Account identifier; Token reference; Product type
- Owned by
- Issuing
Merchant
Who is being paid, and what they said they sell.
MerchantOutletMerchant categoryTerminal
- Critical data elements
- Merchant identifier; Merchant category code; Declared model
- Owned by
- Acquiring
Transaction
The authorisation and everything that follows it.
AuthorisationCleared transactionSettlementRefund
- Critical data elements
- Amount and currency; Authorisation code; Transaction identifier
- Owned by
- Processing
Dispute
The argument about a transaction, and the stages it moves through.
DisputeChargebackRepresentmentArbitration
- Critical data elements
- Reason code; Stage deadline; Disputed amount
- Owned by
- Disputes operations
Scheme rules
The published rules that decide every outcome above.
RuleBulletinCompliance programmeInterchange rate
- Critical data elements
- Rule reference; Effective date; Qualification criteria
- Owned by
- Scheme compliance
Risk
Fraud, exposure and the decisions taken against them.
Risk scoreRule outcomeConfirmed fraudCase
- Critical data elements
- Score; Decision; Fraud marker date
- Owned by
- Risk
Ontology & knowledge graph
The entities and the typed relationships between them — what the agent traverses instead of guessing joins. Select any entity.
Core entityEventReference / classification
Core entity
Cardholder
The person the card was issued to.
- Cardholder holds Account
Core entity
Account
The issuing account behind the card.
- Account issues Card token
- Cardholder holds Account
Core entity
Card token
The surrogate that stands in for the card number.
- Card token used in Authorisation
- Account issues Card token
Core entity
Merchant
The business accepting payment.
- Merchant operates Outlet
- Authorisation acquired for Merchant
Reference / classification
Outlet
A specific location or channel of a merchant.
- Merchant operates Outlet
Event
Authorisation
The real-time approve or decline decision.
- Authorisation acquired for Merchant
- Authorisation clears as Cleared transaction
- Card token used in Authorisation
- Confirmed fraud informs Authorisation
Event
Cleared transaction
The transaction as presented for settlement.
- Cleared transaction settles in Settlement
- Authorisation clears as Cleared transaction
- Dispute challenges Cleared transaction
- Confirmed fraud marks Cleared transaction
Event
Settlement
The movement of funds between parties.
- Settlement priced by Scheme rule
- Cleared transaction settles in Settlement
Event
Dispute
A challenge to a transaction.
- Dispute challenges Cleared transaction
- Dispute raised under Reason code
Reference / classification
Reason code
The scheme code stating why a dispute was raised.
- Reason code governed by Scheme rule
- Dispute raised under Reason code
Reference / classification
Scheme rule
The published provision governing an outcome.
- Reason code governed by Scheme rule
- Settlement priced by Scheme rule
Event
Confirmed fraud
A transaction later confirmed fraudulent.
- Confirmed fraud marks Cleared transaction
- Confirmed fraud informs Authorisation
Taxonomies
The classification hierarchies that make records comparable across systems.
Dispute lifecycle
- Stage
- Action
- Deadline
Chargeback → Representment → 45 calendar days
Merchant classification
- Sector
- Category code
- Risk band
Travel → 4722 → High risk
Decline taxonomy
- Class
- Reason
- Recoverable
Risk → Suspected fraud → Recoverable with step-up
Governed business terms
The definitions an agent must use rather than invent. Most wrong answers in this industry are a term used loosely.
- PAN
- The primary account number. It is the one entity in this model that must never reach a model, a log or a trace.
- Token
- The surrogate that replaces the PAN so downstream systems stay out of PCI scope.
- Authorisation vs clearing
- Authorisation is the real-time decision; clearing is the later presentment for settlement. They routinely differ in amount.
- Reason code
- The scheme code stating why a dispute was raised, and therefore exactly what evidence a representment must contain.
- Representment
- The response to a chargeback, presenting evidence the transaction was valid.
- Interchange qualification
- Whether a transaction met the criteria for the expected rate; failure is a downgrade.
- False decline
- A legitimate transaction refused by risk controls — often a larger cost than the fraud avoided.
- Confirmed fraud
- A transaction later marked fraudulent. It arrives weeks after the event, which is why labels are always partly missing.
03
Part 2 · The architecture
How it is actually built
The layers a deployment needs, what each one holds, and what the engineer owns there.
The reference architecture
Seven layers, with PCI scope and the authorisation latency budget both drawn explicitly.
01/07
Switch, scheme & case sources
Authorisation traffic, scheme clearing files, boarding records, disputes and rulebooks.
Takes in
Nothing. This is the upstream edge.
Hands on
Tokenised transactions, normalised across schemes, plus the rulebook corpus with effective dates.
SystemWhat it doesKey business entities
Authorisation switch
Real-time request and response traffic in ISO 8583 or ISO 20022. Carries the card number, which is why tokenisation happens here and not one hop later.
AuthorisationDecline reasonToken
Scheme clearing files
Daily clearing from the card schemes, in formats that differ by scheme and change on their release calendar rather than yours.
Cleared transactionFeeInterchange
Settlement and funding
Settlement positions, merchant funding and the fees deducted. Where clearing and money finally have to agree, and frequently do not.
Settlement positionFundingAdjustment
Merchant boarding and KYB
Applications, declared business model, verification evidence and limits. The stated model that later transaction behaviour is judged against.
MerchantBusiness modelLimit
Dispute management
Cases, reason codes, deadlines, evidence and outcomes across the full chargeback lifecycle.
DisputeReason codeRepresentmentDeadline
Scheme rulebooks and bulletins
The published rules governing every dispute outcome and interchange qualification, amended continuously by bulletin.
RuleBulletinEffective date
What the engineer owns here
Tokenising card data at the boundary so nothing downstream is ever in PCI scope.
Where this layer fails
Letting a primary account number past the boundary. One PAN in a log or a prompt pulls the entire downstream platform into PCI scope, and unwinding that is an architecture project.
02/07
Ingestion & normalisation
Normalising scheme and processor formats into one transaction model, tokenised throughout.
Takes in
Read-mostly access paths, change feeds and document streams from the systems of record.
Hands on
Replayable, resolved, quality-checked records with their lineage back to the source row.
SystemWhat it doesKey business entities
Change data capture
Reads the source’s own change log rather than polling it, so the platform sees every state a record passed through instead of only where it ended up.
Change eventOperation typeCommit timestamp
Landing and raw zone
Every extract kept as it arrived, immutable and timestamped. The thing you replay from when a downstream definition turns out to have been wrong.
Raw extractBatchWatermark
Document processing
Layout-aware extraction over the unstructured half of the estate: sectioning, tables, signatures, and the page reference every later citation depends on.
DocumentSectionPage reference
Entity resolution
Decides that two records are the same real-world thing, with a survivorship rule and a confidence, so downstream joins are a decision rather than an assumption.
Match candidateSurvivorship ruleCluster
Data quality and contracts
Schema, freshness and volume expectations asserted at the boundary, so a bad load fails loudly here rather than quietly two layers later.
ContractExpectationViolation
Tokenisation boundarythis domain adds
Replaces the primary account number with a surrogate at the edge, so every downstream system, index and log is out of PCI scope by construction.
PANTokenScope boundary
What the engineer owns here
One transaction model across schemes, because reconciliation is impossible without it.
Where this layer fails
Tokenising downstream of the first store. Everything between the switch and that point is now in scope, including the logs you forgot were there.
03/07
Transaction model & semantics
The graph joining cardholder, card token, merchant, transaction, dispute and settlement.
Takes in
Replayable, resolved records with lineage from ingestion.
Hands on
Typed, classified, defined data an agent can be grounded on without inferring meaning.
SystemWhat it doesKey business entities
Business glossary
One agreed definition per term, owned by a named person, so the number an agent quotes means what the business means by it.
TermDefinitionOwnerSteward
Ontology and knowledge graph
The typed entities and relationships the domain actually has, so an agent can traverse "which customers are exposed to this" rather than guess from adjacent text.
EntityRelationshipNodeEdge
Semantic and metrics layer
Metrics defined once, in one place, with their filters and grain. Removes the class of error where the agent computed something plausible and wrong.
MetricDimensionGrainFilter
Classification and policy
Sensitivity labels and the purpose each classification permits, applied at the field level and inherited by everything downstream.
ClassificationPurposePolicy
Lineage and catalogue
Where a value came from and what it touched on the way. The layer that makes an answer defensible rather than merely correct.
Lineage edgeDatasetColumn
What the engineer owns here
One definition of a chargeback ratio, because the scheme has one and yours must match.
Where this layer fails
Letting the model infer meaning from column names. It will, it will be plausible, and nobody will notice until the number reaches a regulator or a board pack.
04/07
Retrieval & grounding
Retrieval over scheme rulebooks, bulletins, dispute precedent and merchant evidence.
Takes in
Typed, classified, defined data from the governance layer.
Hands on
Ranked, permission-trimmed, citable evidence scoped to the caller and the moment.
SystemWhat it doesKey business entities
Hybrid index
Vector and lexical retrieval together, because exact identifiers, codes and clause numbers are the thing semantic search is worst at.
ChunkEmbeddingTermScore
Chunking and metadata
Splits on the document’s own structure and carries effective dates, version and source into every chunk, so a retrieved passage knows when it was true.
ChunkEffective dateVersionSource reference
Security trimming
Applies the caller’s permissions inside the query rather than filtering results afterwards, so the model never sees what the user may not.
PrincipalEntitlementFilter
Graph retrieval
Traverses the knowledge graph for questions that are joins rather than similarity — exposure, genealogy, ownership, causation.
PathHopTraversal
Reranking and citation
Reorders candidates on relevance and returns the passage identifier behind every sentence, so the answer can be checked rather than trusted.
CandidateRankCitation
What the engineer owns here
Answering a reason-code question with the rule, section and effective date cited.
Where this layer fails
Filtering results after retrieval instead of constraining the query. The model has already seen the rows you removed, and it will use them.
05/07
Agent & orchestration
Agents for representment assembly, break diagnosis, merchant review and rule-change impact.
Takes in
Ranked, permission-trimmed, citable evidence from retrieval.
Hands on
Actions taken or proposed, each with the evidence, the identity and the trace behind it.
SystemWhat it doesKey business entities
Agent runtime
Plans, calls tools and holds the loop. Where the step budget, the timeout and the stopping condition are enforced rather than hoped for.
TaskPlanStepTrace
Tool and MCP servers
Typed, permissioned tools with declared schemas. An agent’s real capability surface is this list, which is why the list is a security artefact.
ToolSchemaScopeInvocation
State and memory
Durable task state with checkpoints, so a run that dies mid-way resumes instead of restarting and re-doing side effects.
CheckpointSessionMemory record
Human-in-the-loop gates
Approval steps on the actions that need one, carrying enough context for the approver to actually decide rather than rubber-stamp.
ApprovalThresholdDecision
Workflow integration
Writes back into the systems people already work in, under a service identity with its own audit trail.
Work itemWrite-backActor
Deadline-aware schedulerthis domain adds
Schedules dispute work against scheme calendars so the tail of the queue still meets its stage deadline, not merely the average case.
DeadlineStageQueue position
What the engineer owns here
Keeping every agent off the authorisation path, where its latency cannot be afforded.
Where this layer fails
Optimising average handling time. A representment that is right and late is a total loss, so the tail of the distribution is the only part that matters.
06/07
PCI scope, guardrails & audit
Card-data scoping, model context controls, decision explainability and audit.
Takes in
Proposed actions and drafted responses from the agent layer.
Hands on
Permitted, grounded, logged output — or a refusal with a stated reason.
SystemWhat it doesKey business entities
Policy enforcement
The rules that decide whether an action is permitted at all, evaluated before the action and independently of the model that proposed it.
PolicyDecisionObligation
Input and output screening
Injection detection on the way in, and on the way out the checks for leakage, unsupported claims and content the domain forbids.
PromptResponseViolation
Groundedness checking
Verifies each assertion resolves to retrieved evidence, and fails the response rather than shipping the sentence that does not.
AssertionSupportVerdict
Model risk management
Model inventory, intended use, validation evidence and the sign-off that lets a model be used for a purpose. Not optional in a regulated estate.
ModelIntended useValidationApproval
Audit log
Immutable record of what was asked, retrieved, decided and done — the artefact a reviewer reads when they do not take your word for it.
Audit entryActorEvidence reference
PCI scope enforcementthis domain adds
Field-level controls proving card data cannot enter model context, logs or traces, tested adversarially rather than asserted.
FieldScope testAttestation
What the engineer owns here
Proving that a primary account number cannot reach the model, the log or the trace.
Where this layer fails
A card number reaching a trace. The model never saw it, the observability stack did, and the assessor will not distinguish between those two.
07/07
Evaluation & observability
Representment win rate, break resolution, alert precision and cost per case.
Takes in
Permitted, grounded, logged output from the guardrail layer.
Hands on
Measured quality, cost and latency — and the evidence to change any of the three.
SystemWhat it doesKey business entities
Evaluation harness
Held-out sets and graded runs on every change, so a prompt edit is a measured change rather than a hopeful one.
Eval setCaseScoreBaseline
Regression gate
Blocks a release when quality drops, in CI, on the same evidence for everyone. The difference between a system and a demo.
ThresholdRunGate decision
Tracing
End-to-end spans across retrieval, model and tool calls, so a bad answer can be opened and read rather than argued about.
TraceSpanLatencyToken count
Cost and capacity
Cost per task and per tenant, against throughput and quota. The number that decides whether the pilot can become the rollout.
Cost per taskQuotaThroughput
Drift and feedback
Watches quality against production traffic rather than the test set, and routes real corrections back into the eval suite.
Drift signalFeedbackIncident
What the engineer owns here
Proving the agent won cases it should have won, not merely filed them faster.
Where this layer fails
Evaluating once, before launch. Quality moves with the data, the model and the traffic, and a system with no live measurement has no idea which of the three moved.
Typical tech stack
Models
- Frontier models for rulebook reasoning
- Small models for case triage
- Pattern models on cleared data
Grounding
- Scheme rulebook and bulletin index
- Dispute case precedent
- Transaction knowledge graph
Agents
- Representment assembly agents
- MCP over dispute and settlement systems
- Merchant review agents
Data
- Tokenisation at the boundary
- Scheme format normalisation
- Reconciliation key derivation
Assurance
- PCI scope testing
- Win-rate measurement
- Decision explainability
Runtime
- Off the authorisation path by design
- Deadline-aware scheduling
- Segregated card-data zone
Constraints that shape the design
Card data must stay out of scope
A primary account number in a prompt, a log or a trace expands PCI scope to your whole platform. Tokenise at the boundary and design as though the raw value does not exist.
Authorisation is not your path
The real-time decision has a budget measured in tens of milliseconds. Anything a model contributes here must be pre-computed, not inferred at request time.
Scheme deadlines are absolute
Dispute stages expire on scheme calendars. A representment that is right and late is a loss, so deadline awareness is a first-class scheduling requirement.
Declines are decisions about people
A false decline is a customer told no at a checkout. Explainability is not a compliance nicety here; it is the difference between a fixable rule and an unexplained loss.
04
Part 3 · Getting it done
Where the business and the technology meet
Notice where these use cases are not: on the authorisation path. Everything valuable here sits in the slow half of the business, which is also the half nobody automated.
Use cases, mapped to the chain and the architecture
Filter by stage or by earned autonomy. Selecting a use case jumps the value chain and the architecture to the stage and layer it depends on.
Value chain stage
Autonomy earned
12 use cases
No use cases match that combination.
The delivery playbook
How a payments deployment actually runs.
01
Week 1 — draw the PCI line
Establish where tokenisation happens and prove nothing downstream holds a primary account number. Doing this late means re-architecting rather than adjusting.
02
Week 2 — agree what stays off the authorisation path
Write down explicitly that no agent participates in the real-time decision. This is the commitment that keeps the project deployable.
03
Weeks 3-6 — start with the rulebook
Reason-code interpretation delivers value quickly, touches no card data and builds the citation discipline representment assembly will depend on.
04
Weeks 7-9 — take on representment with deadlines modelled
Build assembly against real scheme deadlines from the first day, because a pipeline that is fast on average and late on the tail loses cases.
05
Weeks 10-12 — scope evidence, win rate and handover
Evidence that card data never entered model context, measure win rate against a baseline, then hand over runbook and scope-testing suite.
The curriculum
8 modules, 80 taught hours, 40 hands-on labs and 8 assessments — every lab provisioned and graded by the SCIKIQ Agentic AI Playground. Open a module to see its labs.
01The SCDAI delivery model in paymentsLanding in a business with a real-time half you must stay out of.10 hrs · 5 labs
Delivery mandateHot path vs cold estateValue sizing on declines and disputesStakeholder mapPCI awarenessThin-slice scoping
01
Decision selectionScore four payments decisions on value, latency and PCI scope.
02
Value sizingSize a false decline, a lost dispute and a settlement break.
03
Scope auditMap where card data flows and where it must stop.
04
Stakeholder mapMap fraud, disputes, merchant risk, settlement and product.
05
Thin sliceScope a rulebook slice that touches no card data at all.
Assessment 01 — Operating model & scope
02Payments data foundationsAuthorisation, clearing, settlement, disputes and the rulebooks over all of them.10 hrs · 5 labs
Authorisation message formatsClearing and settlement filesTokenisationDispute case dataRulebook corporaReconciliation keys
01
Message parsingParse authorisation messages and tokenise card data at the boundary.
02
Scheme normalisationNormalise two scheme clearing formats into one model.
03
Reconciliation keysDerive keys that survive across authorisation and clearing.
04
Case ingestionIngest dispute cases with reason code and deadline preserved.
05
Rulebook ingestionIngest a rulebook with section and effective date preserved.
Assessment 02 — Payments data landscape
03Context engineering under PCI scopeThe module where you learn what may never appear in a prompt.10 hrs · 5 labs
Field scopingToken handlingStructured outputsUncertaintyRefusal on card dataContext budget
01
Field scopingBuild context from tokenised fields only and prove the scope.
02
Leak testingAttempt to elicit a card number and prove it is unreachable.
03
Structured findingsEmit dispute findings as a typed, validated structure.
04
RefusalMake the agent refuse a request that would require card data.
05
Context budgetCut context cost on a high-volume case triage agent.
Assessment 03 — Context engineering & PCI
04Grounding on scheme rulesThe corpus that decides every dispute outcome, and that changes by bulletin.10 hrs · 5 labs
Rule retrievalBulletin change trackingEffective datingCase precedentCitationsRetrieval evals
01
Rule retrievalAnswer a reason-code question citing rule and section.
02
Effective datingReturn the rule version operative on the transaction date.
03
Bulletin trackingDetect what a bulletin changed and which rules it touched.
04
Citation contractCite rule, section and effective date on every answer.
05
Retrieval evalsBuild a specialist-labelled rule question set and measure accuracy.
Assessment 04 — Retrieval & grounding
05Dispute and risk agent designEvidence assembly against a deadline, and pattern work on late labels.10 hrs · 5 labs
Workflow vs agentDeadline-aware orchestrationEvidence assemblyLate-label learningExplainabilityEscalation
01
Representment agentAssemble an evidence pack against the rule requirement.
02
Deadline awarenessSchedule work so scheme deadlines are never missed on the tail.
03
Late labelsHandle confirmed-fraud labels that arrive weeks after the event.
04
ExplainabilityExplain a decline cohort in terms a product manager can act on.
05
EscalationDefine when a case must go to a specialist and prove it does.
Assessment 05 — Agent design for disputes & risk
06Integrating with case, settlement and scheme systemsRead widely, write only into the case record, and never into the switch.10 hrs · 5 labs
MCP over case and settlement systemsScheme file handlingWrite-backLatency isolationIdentityError handling
01
MCP over casesExpose dispute case lookups as typed read tools.
02
Settlement readsQuery settlement positions within their own permission model.
03
Case write-backAttach an assembled pack to a case under a traceable identity.
04
Latency isolationProve no agent component sits on the authorisation path.
05
IdentityBind agent access to portfolio and role entitlements.
Assessment 06 — Systems integration
07PCI, fairness and securityThe module that decides whether this is allowed near cardholder data at all.10 hrs · 5 labs
PCI DSS scopeTokenisation architectureDecline fairnessOWASP LLM Top 10Injection via merchant contentIncident response
01
Scope proofEvidence that card data cannot reach model, log or trace.
02
Tokenisation designArchitect tokenisation so downstream systems stay out of scope.
03
Fairness reviewTest decline explanations for systematic disparity across cohorts.
04
Injection defenceDefend against instructions embedded in merchant site content.
05
Red teamRun an OWASP LLM Top 10 pass over the representment pipeline.
Assessment 07 — PCI, fairness & security
08Production, win rate and cost per caseFiling faster is not the outcome. Winning cases that should be won is.10 hrs · 5 labs
Eval suitesWin-rate measurementDriftDeadline complianceCost per caseHandover
01
Eval gateGate deployment on rule-answer accuracy regression.
02
Win-rate studyMeasure representment win rate against a pre-agent baseline.
03
Drift watchDetect drift after a scheme rule release.
04
Cost per caseMeasure and reduce cost per dispute handled.
05
HandoverProduce runbook, PCI scope evidence and win-rate baseline.
Assessment 08 — Production & outcomes
Two capstones — 20 hours
End-to-end agent design, development, deployment and testing, 10 hours each. Reviewed by a Senior SCDAI Engineer against a published rubric.
Capstone A — Representment assembly agent
Build an agent that reads a dispute, determines what the operative scheme rule requires, assembles the available evidence and drafts the representment — citing rule, section and effective date, never missing a scheme deadline, and with a measured win rate against a pre-agent baseline.
Capstone B — Decline cohort explainer
Build an offline agent that explains a false-decline cohort in terms of the rules that produced it and quantifies the cost of each, operating entirely on tokenised data with evidence that no primary account number reached the model, the logs or the traces.
What you deliver, and how it is marked
- A running agent, deployed on the program's target stack, reachable by a reviewer.
- An architecture note: boundaries, tools, autonomy level and the trade-offs you took.
- A versioned eval set with a baseline and your final scores.
- A trace walkthrough of one success and one deliberate failure.
- Cost per task, measured — not estimated.
- A runbook and rollback path a client team could operate on Monday.
Problem fit15%Is this a decision worth automating, scoped to a defensible boundary?
Architecture20%Right pattern for the constraints; autonomy earned, not assumed.
Grounding & accuracy20%Measured groundedness against the eval set, with the failures named.
Safety & compliance20%Domain controls actually enforced, and demonstrably so.
Operability15%Traces, runbook, rollback, cost — could someone else run this?
Communication10%Can a client executive follow the reasoning in ten minutes?
One lab, start to finish
Every lab in this program follows the shape below. This is lab 05 in full — the brief you are given, the environment that is provisioned for you, the code you start from and the assertions that decide whether you passed.
Module 05 · Dispute and risk agent design
Representment against the operative rule
Assemble a chargeback response that cites the rule version in force on the transaction date.
The brief
You are given 200 disputes with reason codes, the transaction and evidence available for each, and a scheme rulebook with three bulletin revisions across the period. Assemble the representment for each: what the operative rule required, which evidence satisfies it, and what is missing. Answering from the current rulebook rather than the one in force is the failure this lab catches.
Provisioned for you
- 200 disputes across 9 reason codes
- Rulebook with 3 dated bulletin revisions
- Evidence store: receipts, delivery proof, AVS results
- Labelled key: outcome per dispute
You start from this
def representment(dispute, rulebook, evidence):
"""Assemble the response for one dispute.
The operative rule is the version in force on the TRANSACTION date,
not today's. Bulletins move requirements; answering from the current
text loses cases that were winnable.
"""
rule = rulebook.operative(dispute.reason_code, dispute.transaction_date)
# match required evidence to what exists; state plainly what does not
raise NotImplementedErrorWhat the grader asserts
- Every response cites rule, section and the effective date in force on the transaction date
- No response is assembled from a rulebook revision published after the transaction
- Missing evidence is reported explicitly rather than the response being submitted incomplete
- No dispute is assembled past its scheme stage deadline
- No card number appears in any prompt, log or trace produced by the run
05
Assessment
Assessed, not attended
Every module ends with a timed, randomised assessment delivered through the SCIKIQ Agentic AI Playground. The certificate requires a pass on all of them plus two reviewed capstones.
Assessment blueprint
What each test covers, how long it runs, and how many items are currently in the versioned bank behind it.
| # | Assessment & coverage | Items | Time | In bank |
|---|---|---|---|---|
| 01 | Operating model & scopeDelivery mandateHot vs cold pathValue sizingPCI scope | 25 | 35 min | 3 |
| 02 | Payments data landscapeMessage formatsClearing and settlementTokenisationRulebooks | 25 | 35 min | 2 |
| 03 | Context engineering & PCIField scopingToken handlingRefusalStructured outputs | 25 | 35 min | 2 |
| 04 | Retrieval & groundingRule retrievalEffective datingBulletinsRetrieval metrics | 25 | 40 min | 2 |
| 05 | Agent design for disputes & riskEvidence assemblyDeadlinesLate labelsExplainability | 25 | 40 min | 2 |
| 06 | Systems integrationMCP designSettlement dataWrite-back safetyLatency isolation | 25 | 35 min | 2 |
| 07 | PCI, fairness & securityPCI scopeTokenisationFairnessLLM security | 30 | 45 min | 2 |
| 08 | Production & outcomesEval gatingWin rateDeadline complianceEconomics | 30 | 45 min | 2 |
Single best answerOne defensible option among plausible distractors drawn from real field mistakes.
Scenario judgementA client situation with constraints; you pick the action a Senior SCDAI Engineer would take.
Architecture selectionGiven non-functional requirements, choose the pattern and justify the trade-off.
Failure diagnosisA trace, an eval report or a cost curve — identify the root cause.
- Each module ends with a timed assessment; the program certificate requires a pass on every one.
- Items are drawn at random from a versioned bank, so no two learners sit an identical paper.
- Pass mark is 70%. Two retakes are included, each with a fresh draw.
- Scenario items carry double weight — they are the ones that predict field performance.
- Capstones are reviewed against a published rubric by a Senior SCDAI Engineer, not auto-graded.
Try four questions from the bank
Real items, drawn from 17 in this program's bank — weighted toward the scenario and diagnosis types, because those are the ones that predict field performance. Instant feedback, nothing saved.
Four sample items — one attempt each, then the reasoning is shown.
Q1A processor asks you to put a model in the authorisation path. What is your answer?
The real-time decision has no room for inference. The engineering judgement in this sector is knowing which half of the business you are in.
Q2A primary account number appears in an application log. What is the consequence?
Scope follows the data. One PAN in a log pulls the log store, its backups and its consumers into the assessment, which is why the boundary is architectural.
Q3An agent is asked a question that would require the full card number. What should it do?
Refusal is the only correct behaviour. Retrieving the value at all, even without displaying it, places the retrieval path in scope.
Q4A reason code question is answered from the latest rulebook revision. The transaction is eight months old. What is wrong?
Requirements move with bulletins. Applying today’s requirement retrospectively produces a representment that fails on evidence nobody was ever asked to keep.
06
Career & outcomes
What this makes you, and where it goes next
The same ladder whichever specialisation you enter through — what changes is the domain you go deep in. Below: how the program is delivered, the skills it moves, the roles it leads to, and the specialisations closest to this one.
Available two ways
The same labs, assessments and capstones, delivered to an enterprise cohort or to individual professionals.
B2B
Direct to enterprise
Cohorts of 20 to 2,000+ on your own tenancy, with your data patterns and your cloud. Skill-gap baselining up front, per-team mastery reporting throughout, and capstones scoped against your real backlog so the output is deployable work.
- Private cohort on your tenancy
- Baseline skills assessment before kick-off
- Capstones scoped to your backlog
- Per-team mastery dashboards for L&D
- Optional Senior SCDAI Engineer architecture reviews
B2C
Direct to individual professionals
The same labs, assessments and capstones for individual engineers and analysts, run on shared infrastructure with a fixed cohort calendar. You leave with a graded portfolio, not a certificate of attendance.
- Fixed-date cohorts, self-paced within them
- Same graded labs and item bank
- Portfolio-ready capstones you own
- Certificate on a pass in every module
- Community and office-hours access
Skill matrix
Find your row and aim one column right. The Playground scores you against this after every module.
| Skill | Beginner | Intermediate | Advanced |
|---|---|---|---|
| Payments domain fluency | Knows the parties. | Maps the chain from authorisation to interchange. | Sizes decline, dispute and break value credibly. |
| Scope engineering | Aware of PCI. | Designs tokenisation so downstream stays out of scope. | Evidences that card data cannot reach model, log or trace. |
| Rule intelligence | Retrieves a rule. | Returns the version operative on the transaction date. | Runs rulebook retrieval with measured, specialist-labelled accuracy. |
| Context engineering | Writes clear prompts. | Structures retrieval, tools and state deliberately. | Designs context strategy for reliability and cost at scale. |
| Retrieval & grounding | Builds basic vector search. | Tunes chunking, hybrid search and reranking. | Designs graph + vector grounding with measured recall. |
| Agent orchestration | Runs a single tool-calling agent. | Builds supervised multi-step and multi-agent flows. | Designs autonomy boundaries and failure containment. |
| Tool & system integration | Calls a documented API. | Writes an MCP server over a system of record. | Designs a least-privilege tool estate across systems. |
| Evaluation | Eyeballs outputs. | Builds labelled eval sets and regression gates. | Runs online evals with drift and judge calibration. |
| Observability & cost | Reads logs. | Traces runs, tracks tokens and latency. | Owns cost per task and capacity planning in production. |
| Security & guardrails | Adds output filters. | Mitigates the OWASP LLM Top 10 in a build. | Threat-models an agent estate and proves controls. |
| Client delivery | Takes notes in a workshop. | Runs discovery and scopes a thin slice. | Owns the account technically, from scope to handover. |
Where it takes you
The SCDAI ladder is the same whichever specialisation you enter through — what changes is the domain you go deep in.
01
Data and AI EngineerEntry
Python, LLM APIs, first RAG build, prompt and context basics.
02
Associate Data and AI EngineerPractitioner
Client-facing discovery, tool integration, agent build under supervision.
03
SCIKIQ Certified Data and AI EngineerSpecialist
Owns a deployment end to end — scoping, build, evals, handover.
04
Senior Data and AI Engineer / Domain LeadSenior
Multi-agent architecture, regulated deployments, reference patterns for the practice.
05
AI Architect / Practice LeadLeadership
Portfolio of accounts, delivery standards, hiring and capability strategy.
Terms worth knowing
- PCI DSS
- The card industry security standard; its scope is what makes card data architecturally special.
- PAN
- Primary Account Number — the card number, and the thing that must never reach a model.
- Tokenisation
- Replacing a card number with a surrogate so downstream systems stay out of scope.
- Interchange
- The fee passed between acquirer and issuer, whose rate depends on qualification.
- Reason code
- The scheme code stating why a dispute was raised, and therefore what evidence is required.
- Representment
- The response to a chargeback, presenting evidence that the transaction was valid.
- False decline
- A legitimate transaction refused by risk controls, and often the largest hidden cost.
- Transaction laundering
- Processing for a business other than the one that was boarded.
- SCDAI
- SCIKIQ Certified Data and AI Engineer — the credential this program awards.
- SCDAI engineer
- An engineer embedded with the customer who turns their constraints into a working system.
- Thin slice
- The narrowest end-to-end path through a workflow that still produces business value.
- Agentic RAG
- Retrieval where the agent decides when, what and how often to retrieve.
- MCP
- Model Context Protocol — open standard connecting an agent to tools and data.
- A2A
- Agent2Agent — protocol for agent-to-agent delegation across vendors.
- Eval set
- A labelled, versioned set of cases an agent must pass before release.
- LLM-as-judge
- Using a model to score outputs, calibrated periodically against human ratings.
- Guardrail
- An enforced constraint on an input, output or action — not a prompt request.
- Human-in-the-loop
- A required human approval step before a consequential action executes.
- Cost per task
- Total token, tool and compute cost of one completed unit of work — the engineer's unit economic.
- Golden path
- The reference architecture a practice standardises on so deployments stay reviewable.
- Handover
- The point at which the client can operate, evaluate and change the system without the engineer.
Related programs
Skill a team, or join a cohort
B2B cohorts run on your tenancy with capstones scoped to your backlog. B2C cohorts run on a fixed calendar.
07
Enrolling
What you need, what you get, and what it costs
Stated plainly enough to rule yourself in or out without a sales call: the prerequisites, how the program runs, exactly what the credential is worth, and the questions everyone asks.
Before you start
Stated plainly so you can rule yourself in or out without a sales call. Nothing here is a formal qualification — it is what the first lab assumes you can already do.
Technical
You should already be able to do these
- Comfortable in Python: functions, typing, virtual environments, reading a stack trace
- Have called an LLM API and handled a structured response
- Git, the command line, and reading someone else’s code without panic
Domain
What we assume, and what we teach
- Know roughly what happens between tapping a card and a merchant being paid
- Comfort with the idea that some data may never enter your system at all
Time and access
What the program asks of your week
- A machine that can run a browser and a terminal — labs run in the Playground, not locally
- Roughly 8 hours a week for the taught weeks, plus 20 hours for the two capstones
How it runs
Cohort dates and pricing are confirmed on enquiry rather than printed here, because both move with the intake.
- Format
- Self-paced within a fixed cohort window, delivered in the SCIKIQ Agentic AI Playground
- Taught hours
- 80 hours across 8 modules
- Capstones
- 20 hours — two end-to-end builds, reviewed not auto-graded
- Typical duration
- 10–12 weeks at around 8 hours a week
- Level
- Intermediate → Advanced
- Built for
- Engineers and analysts deploying AI across issuing, acquiring and payment processing
- Next cohorts
- — confirmed on enquiry
- Pricing
- — confirmed on enquiry
The credential
The credential is awarded per specialisation, so it names the domain or stack you were assessed in rather than claiming general competence. On this program the badge reads SCDAI — Cards & Payments.
How it is earned
- A pass at 70% or above on every module assessment — not an average across them
- Both capstones reviewed against the published rubric by a Senior SCDAI Engineer
- All labs submitted and machine-graded green
- Awarded as
- A verifiable digital badge with a public credential record
- Valid for
- Two years from award
- Recertification
- One current-year assessment plus a refreshed capstone
- Retakes
- Two included per assessment, each with a fresh item draw
- Named specialisation
- The badge states the domain or stack, e.g. SCDAI — Healthcare
- Verification
- Third parties confirm a holder from the credential record, no login required
A certificate that cannot be checked is decoration. Every award resolves to a record showing the specialisation, the award date and the assessments passed.
The certificate you leave with
This is the credential the program awards, shown exactly as it is issued — with the specialisation named, the assessment record attached and a verification link anyone can check without an account.
SCIKIQ Data Academy
Certificate of Professional Certification
This is to certify that
Your name
has been assessed and certified as
SCIKIQ Certified Data and AI Engineer
Cards & Payments
- Specialisation
- Cards & Payments
- Assessments passed
- 8 of 8, each at 70% or above
- Labs graded
- 40 of 40 machine-graded green
- Capstones reviewed
- 2, against the published rubric
- Taught hours
- 80 across 8 modules, plus 20 capstone hours
AwardedOn completion
Valid untilTwo years from award
Credential IDSCDAI-CARDS-PAYMEN-<issued>
Senior SCDAI Engineer, Certification Board
- 01The specialisation is on the certificate
Not “Data and AI Engineer” but the domain or stack you were actually assessed in. A general claim would be a weaker one.
- 02The assessment record travels with it
Modules passed, labs graded and both capstones reviewed — so the credential states what was measured rather than that you attended.
- 03Anyone can verify it, without a login
The credential ID resolves to a public record showing the specialisation, the award date and the assessments passed.
Share it on LinkedIn
Add it to your LinkedIn profile in one step. The link pre-fills the certification fields from the credential record, so the entry on your profile matches the record a reader can check.
Add to LinkedIn profile The button is live on your real certificate; here it opens LinkedIn pre-filled with this specialisation so you can see exactly what the profile entry will say.A certificate that cannot be checked is decoration. Every award resolves to a record showing the specialisation, the award date and the assessments passed.
Questions we get asked
The objections that come up in every conversation about this program, answered without the brochure voice.
Is this a course or a certification?
Both, and the second is the point. Eight timed assessments and two reviewed capstones stand between you and the credential, so a pass means someone measured the skill rather than recorded your attendance.
How is it self-paced without falling apart?
Every lab is provisioned, graded and unblocked by the Playground rather than by an instructor. That is what lets a cohort of 2,000 cost the same faculty time as a cohort of 20 — and why you are never waiting on someone to mark your work.
What if I fail an assessment?
Two retakes are included per assessment, each drawing a fresh item set from the bank, so a retake is a genuinely new paper rather than the same questions again.
Do I need my own cloud account?
For the domain specialisations, no — labs run in provisioned sandboxes. For the four tech-stack programs you will want access to that platform, since deploying into a real subscription is much of the point.
Can we run this privately for our team?
Yes. B2B cohorts run on your own tenancy with your data patterns, a skills baseline before kick-off, per-team mastery reporting, and capstones scoped against your actual backlog so the output is deployable work rather than an exercise.
Which specialisation should I take?
Take the domain you deploy into. If you move across industries, take a tech-stack program instead and pick up domain context on the engagement. The chooser on the programs page will narrow it.
How current is the material?
The trends, platform capabilities and regulatory positions are reviewed each quarter, and every external claim on these pages links to its source so you can check the date yourself.
What do I actually leave with?
A graded portfolio: forty machine-graded labs, two reviewed end-to-end agent builds with measured evaluation and cost per task, and a verifiable credential naming your specialisation.
Still deciding?
Tell us the systems you deploy into and we will say plainly whether this specialisation is the right one — or which of the 21 is.