Blog on Corebaseit — POS · EMV · Payments · AI

Edge AI: Why Intelligence Is Moving to the Boundary — and What It Takes to Get There

contact@corebaseit.com (Vincent Bevia) — Sun, 19 Apr 2026 10:00:00 +0100

There is a quiet architectural shift happening beneath the surface of the AI conversation. While the public discourse fixates on data center GPU clusters and trillion-parameter models, a different engineering problem is gaining urgency: how do you push intelligence out to the edge — to sensors, factory floors, autonomous vehicles, medical devices, and payment terminals — where latency, bandwidth, power, and privacy constraints make the cloud either impractical or unacceptable?

Edge AI is not a future speculation. The IEEE Computer Society’s 2026 Technology Predictions report ranks it among the top technologies expected to succeed this year, noting that edge AI will “enable privacy-preserving, low-latency, energy-efficient, generative intelligence via small language models on resource-constrained devices, extending AI access to remote settings and extreme environments where continuous connectivity is not guaranteed.” That is a precise and honest framing. It also hints at how hard the engineering really is.

After reading several recent IEEE papers covering distributed intelligence for edge networks, AI chip architectures, edge AI education, 2026 technology predictions, and system-level trustworthiness, I wanted to organize what these pieces collectively reveal about the current state of edge AI — where the real bottlenecks are, what the architecture looks like, and why trust in these systems demands more than model accuracy alone.

The Case for Edge: Latency, Privacy, and the Limits of Centralization

The traditional cloud model — collect data at the edge, ship it to a centralized cluster, run inference or training, return the result — works well when bandwidth is cheap, latency is tolerable, and privacy is not a binding constraint. In many real-world applications, none of those conditions hold.

An autonomous vehicle cannot wait 200 milliseconds for a cloud round trip to decide whether the object ahead is a pedestrian. A factory sensor detecting a bearing failure needs a corrective response in single-digit milliseconds, not after a data upload and cloud inference cycle. A medical wearable handling patient vitals cannot stream raw biometric data to an external server without running into regulatory and ethical walls.

These are not edge cases (no pun intended). They are the default operating conditions for a growing class of applications — from Industry 4.0 and smart grids to point-of-sale terminals and agricultural monitoring. The European Telecommunications Standards Institute (ETSI) has formalized this direction through the concept of zero-touch network provisioning: the idea that the infrastructure itself should be automated, self-configuring, and capable of operating with minimal or no human intervention. That vision depends entirely on intelligence at the edge.

The architectural consequence is clear. You cannot centralize everything. But distributing intelligence across heterogeneous, resource-constrained devices introduces an entirely different class of engineering problems.

Distributed AI and Zero-Touch Provisioning: The Architecture

A research team from TU Wien, University of Oulu, University of Tartu, and the Indian Institute of Information Technology has proposed a framework combining Distributed AI (DAI) with zero-touch provisioning (ZTP) for edge networks. The architecture targets the device–edge–cloud computing continuum and rests on two pillars.

Edge intelligence for zero-touch networks. Data processing at the local level grants edge devices the ability to independently assess and respond to data without relying on centralized decision making. Distributed decision-making processes reduce latency, optimize network resources, and support real-time responsiveness. Machine learning models deployed at the edge enable predictive maintenance, anomaly detection, and dynamic load balancing — capabilities that let networks function effectively with reduced human involvement.

DAI for edge networks. DAI facilitates the deployment of AI capabilities to the periphery of network infrastructures. Edge devices equipped with AI models can make real-time decisions, process data locally, and function independently. The key advantage of DAI over centralized edge AI is structural: DAI systems are resilient, flexible, and loosely coupled by definition. They do not require all relevant data to be gathered in a single location. Instead, they work with local subsets of data, preserving privacy and reducing communication costs.

The comparison between centralized edge AI and ZTP-enabled distributed edge AI is instructive:

Parameter	Centralized Edge AI	Distributed Edge AI (ZTP)
Model	Traditional supervised learning	Unsupervised and policy-based reinforcement learning
Privacy	No privacy for handling user data	Supports privacy and security in data handling
Training time	Large-data training exponentially increases time	Local edge training optimizes time
Scalability	Not scalable	Highly scalable
Heterogeneity	Low	High
Automation	Medium	High

The framework also introduces edge resource federation — a strategy for pooling edge resources across different providers into a unified platform. When one edge device is overloaded, it can interoperably communicate with nearby underloaded devices or cloud servers to share the workload. Network function virtualization, software-defined networking, containerization, and multiaccess edge computing act as critical enablers for this federation model.

A concrete example from the Industry 4.0 domain clarifies the stakes. When a machine sensor on a factory floor detects a possible issue, edge AI can recognize it, implement corrective measures, and reduce delay in critical decision making — all locally. A centralized or cloud-based system would require data transmission to a distant server for analysis, potentially causing delays and operational hazards in time-sensitive manufacturing environments.

The Hardware Problem: Edge AI Chips and Energy Efficiency

You cannot run a transformer model on a device that draws 500 milliwatts from a coin-cell battery using the same architecture that powers a data center GPU. The hardware constraints at the edge are qualitatively different, and they demand a fundamentally different approach to chip design.

Research from Japan’s National Institute of Advanced Industrial Science and Technology (AIST) details the architecture of edge AI chips and why energy efficiency is the defining constraint for cyberphysical systems (CPS) applications such as autonomous driving and factory automation.

Spatial vs. Temporal Architecture

The critical distinction is between the temporal architecture used in GPUs and the spatial architecture (dataflow processing) used in purpose-built AI chips.

In a GPU’s temporal architecture, massive arithmetic logic units (ALUs) read from and write to a shared register file, operating in parallel. This is fast but energy-hungry, because every operation requires central memory access.

In a spatial architecture, processing elements (PEs) are organized in tiles, each with its own ALU, register file, and control circuit. Data — activations, weights, partial sums — moves directly from one PE to another, reducing memory access energy. Filter weights in a convolutional neural network are reused by storing them in a PE’s register file and transferring partial sums between PEs, making computation significantly more energy-efficient.

This is why spatial architectures are the foundation of edge AI chips: they trade peak throughput for dramatically better performance-per-watt.

Precision Reduction as an Energy Multiplier

The most effective lever for improving edge AI energy efficiency is reducing computational precision. In cloud training, FP32 or FP16 is standard. For edge inference, the picture looks very different:

INT8 quantization reduces energy to roughly 1/30th (for addition) and 1/19th (for multiplication) compared to FP32, with less than 3% accuracy degradation on image recognition tasks.
INT4 formats push efficiency further for inference workloads.
Binarized Neural Networks (BNNs) replace multipliers with XNOR gates and accumulators with population counters, achieving extraordinary efficiency. Intel has demonstrated a BNN accelerator reaching 617 TOPS/W — orders of magnitude beyond conventional architectures.

The trade-off with BNNs is accuracy: on simple tasks like CIFAR-10, accuracy drops by only ~1% from FP32. On complex tasks like ImageNet, it worsens by ~16%. The practical solution is mixed-precision computation, optimizing the bit width at each layer of the network to balance accuracy and efficiency.

The 2026 IEEE Technology Predictions report reinforces this trajectory. Prediction #22 (New Processors) calls for “three orders of magnitude performance improvement and three orders of magnitude power consumption reduction” through new technologies and full 3D architectures with AI-based design strategies. Prediction #17 (In-Memory Computing) highlights analog in-memory computing as a way to bring computation directly into memory arrays, “dramatically reducing data movement, the dominant source of power and latency in today’s AI systems.”

These are not incremental improvements. They represent a fundamental rearchitecting of the compute substrate to match the constraints of the edge.

Teaching the Edge: Hardware–Software Co-Design

One of the less discussed challenges is the talent pipeline. Edge AI requires a blend of skills — hardware awareness, software optimization, systems thinking — that most computer science curricula do not yet teach as an integrated discipline.

A team at the University of Texas at Austin has developed an undergraduate edge AI course built around a hardware–software co-design approach. Students work directly with physical edge devices (Raspberry Pi 3B+ and Odroid MC1 clusters), performing real-time power, latency, and temperature measurements while training, deploying, and optimizing neural network models.

The course architecture mirrors the real engineering workflow:

Train models in the cloud (on GPU clusters from the Texas Advanced Computing Center).
Deploy models on edge devices.
Measure the cyberphysical impact — power consumption, latency, thermal behavior.
Optimize using pruning and quantization.
Redeploy and remeasure until convergence.

Students work with both PyTorch/ONNX and TensorFlow/TensorFlow Lite stacks, gaining cross-framework fluency. The course culminates in a competition (the “Game of Compressions”) where teams optimize models for lowest latency, lowest energy, or best figure of merit (accuracy divided by the product of latency and energy).

The results are encouraging: across 54 student teams over three semesters, the best FoM result achieved 75.8% accuracy on CIFAR-10 with an average latency of 0.72 ms per image and average energy of 8.51 mJ per image. All teams successfully deployed pruned and quantized models on edge devices.

This kind of hands-on, co-design education is exactly what the field needs. Edge AI is not a software-only or hardware-only problem. It is a systems problem, and the people building these systems need to understand both sides of the stack — and the interactions between them.

Trustworthiness: The System-Level Problem That Edge Makes Harder

Here is where the conversation gets uncomfortable. Edge AI amplifies every dimension of the trustworthiness challenge.

A recent IEEE paper by Vieira makes a compelling case that the AI community has a trustworthy AI misconception: the assumption that if the model is fair, robust, and explainable, then the system is trustworthy. That assumption is wrong for cloud-deployed AI. It is catastrophically wrong for edge AI.

Why Model-Level Trust Is Insufficient

Trust is a property of the entire system, not just of one component. An AI model depends on the data it receives, the infrastructure in which it operates, and the mechanisms through which its decisions are implemented. A well-designed and explainable AI model may still produce harmful outcomes if the data pipeline is flawed, the storage system is insecure, or the decision-making process lacks human oversight.

The real-world evidence is damning:

Amazon’s AI recruiting tool penalized applications from women despite attempts to remove gender bias — because the historical hiring data was structurally biased.
Google Health’s diabetic retinopathy screening had high diagnostic accuracy in the lab but failed in deployment because nurses had to manually upload high-quality images under strict standards that real clinics could not consistently meet.
The Epic Sepsis Model was widely adopted but poorly calibrated to individual hospital populations, generating high false-positive rates and missing true sepsis cases — overwhelming clinicians with alerts and leading to delayed treatment.
Waymo’s vehicle routing bug showed that even when the perception system correctly identified obstacles, a failure in the integration between AI perception and the route planner led to indecision, requiring remote human assistance.

In every case, the AI model was not the primary point of failure. The failure emerged from the system surrounding the model: data pipelines, infrastructure dependencies, human–system interaction design, or governance gaps.

The Edge Amplification Effect

Now consider what happens when you push these systems to the edge:

Data pipelines are more fragile — intermittent connectivity, heterogeneous sensors, constrained local storage.
Infrastructure is more diverse — different device manufacturers, operating systems, thermal environments, power profiles.
Human oversight is harder — edge systems are designed to operate autonomously, often in environments where human monitoring is minimal or absent.
Governance is more complex — edge deployments span jurisdictions, regulatory frameworks, and organizational boundaries.

The ZTP framework explicitly acknowledges these challenges. Cascading failures at the edge can propagate upward, and ZTP has no built-in mechanism to control such cascades. Anomaly detection in ZTP does not yet cover the full computing continuum. Security across autonomous systems running with no human intervention is inherently more difficult.

Vieira proposes a multilayered trust model that extends beyond the AI/ML component to encompass:

Data trustworthiness — validity, absence of bias, security throughout the data lifecycle.
Infrastructure trustworthiness — resilient deployment, continuous monitoring, graceful failure recovery.
Human–system trustworthiness — usability, interpretability, governance features ensuring users understand and control AI-assisted decisions.
Regulatory and ethical trustworthiness — legal compliance, transparency, accountability mechanisms.

For edge AI systems, all four layers must be engineered deliberately. Assuming that a technically accurate model will produce trustworthy outcomes in a distributed, heterogeneous, partially autonomous environment is a systemic risk.

What Comes Next: Research Directions and Open Problems

The literature converges on several urgent research directions for edge AI:

Lightweight AI/ML. Resource-constrained edge nodes need algorithms that minimize both resource usage and computation time without affecting prediction accuracy. Model compression, knowledge distillation, and novel architectures designed for constrained environments remain active research areas.

Privacy-preserving intelligence. Federated learning and differential privacy techniques are essential for training models across distributed edge devices without centralizing sensitive data. The privacy challenge at the edge is not theoretical — it is a regulatory requirement in medical, financial, and personal-data domains.

Semantic interoperability. The computing continuum interconnects devices that are heterogeneous in technologies, standards, and data formats. Bridging the interoperability gap with intelligent protocols is necessary before ZTP can scale to the full continuum.

Explainability and causality. ZTP will autonomously select configuration states for large distributed systems. Developing sidecar tools that can explain why a specific configuration was selected — using causal reasoning rather than post-hoc correlation — is essential for auditability and trust.

Generative AI at the edge. The 2026 predictions identify edge deployment of small language models as a near-term reality. But tracing the accuracy of generative AI decisions on the fly, and identifying which computing nodes can actually perform generative inference within the continuum, remain open challenges.

System-level assurance. Moving beyond model-centric assessment to develop evaluation methodologies encompassing data integrity, infrastructure dependability, human–AI interaction, and governance transparency. This includes trustworthiness maturity models, assurance case approaches adapted from safety-critical domains, and risk propagation modeling across subsystems.

The Bottom Line

Edge AI is not about shrinking a cloud model to fit on a small device. It is about redesigning the entire stack — hardware, software, networking, governance, and trust — for an operating environment where latency is measured in milliseconds, power in milliwatts, connectivity in intermittent bursts, and human oversight in occasional remote glances.

The hardware is evolving: spatial architectures, mixed-precision compute, BNNs, in-memory computing, and new processor paradigms are closing the efficiency gap. The software is adapting: ZTP, edge federation, DAI, and federated learning are providing the distributed intelligence frameworks. The educational pipeline is catching up: co-design curricula are producing engineers who understand both sides of the stack.

But the trust problem remains the hardest. Every system-level failure documented in cloud-deployed AI — biased data, fragile infrastructure, inadequate human oversight, governance gaps — is amplified at the edge. Building trustworthy edge AI systems requires treating trust as a multilayered, system-wide engineering discipline, not a model-level checkbox.

The edge is where AI meets the physical world. Getting it right matters more than getting it fast.

References

A. Hazra, A. Morichetta, I. Murturi, L. Lovén, C. K. Dehury, V. C. Pujol, P. K. Donta, and S. Dustdar, “Distributed AI in Zero-Touch Provisioning for Edge Networks: Challenges and Research Directions,” IEEE Computer, vol. 57, no. 3, pp. 69–78, Mar. 2024, doi: 10.1109/MC.2023.3334913.
H. Fuketa and K. Uchiyama, “Edge Artificial Intelligence Chips for the Cyberphysical Systems Era,” IEEE Computer, vol. 54, no. 1, pp. 84–88, Jan. 2021, doi: 10.1109/MC.2020.3034951.
A.-J. Farcas and R. Marculescu, “Teaching Edge AI at the Undergraduate Level: A Hardware–Software Co-Design Approach,” IEEE Computer, vol. 56, no. 11, pp. 30–38, Nov. 2023, doi: 10.1109/MC.2023.3295755.
C. Ebert, I. El Hajj, E. Frachtenberg, A. Lysko, D. Milojicic, R. Saint Nom, S. Sinha, and J. Toro, “Technology Predictions 2026,” IEEE Computer, vol. 59, no. 4, pp. 172–181, Apr. 2026, doi: 10.1109/MC.2026.3660461.
M. Vieira, “Why We Should Trust Systems, Not Just Their AI/ML Components,” IEEE Computer, vol. 58, no. 11, pp. 84–94, Nov. 2025, doi: 10.1109/MC.2025.3604335.
V. Sze, Y. Chen, T. Yang, and J. S. Emer, “Efficient Processing of Deep Neural Networks: A Tutorial and Survey,” Proceedings of the IEEE, vol. 105, no. 12, pp. 2297–2329, 2017, doi: 10.1109/JPROC.2017.2761740.
J. Gallego-Madrid, R. Sanchez-Iborra, P. M. Ruiz, and A. F. Skarmeta, “Machine Learning-Based Zero-Touch Network and Service Management: A Survey,” Digital Communications and Networks, vol. 8, no. 2, pp. 105–123, Apr. 2022, doi: 10.1016/j.dcan.2021.09.001.
S. Han, H. Mao, and W. J. Dally, “Deep Compression: Compressing Deep Neural Networks with Pruning, Trained Quantization and Huffman Coding,” arXiv:1510.00149, Oct. 2015.

Feasibility Assessment: Q-Learning Suitability for Organizational Decision Systems

contact@corebaseit.com (Vincent Bevia) — Mon, 13 Apr 2026 12:00:00 +0100

1. Architectural foundation: the Q-learning paradigm

Q-learning represents a paradigm shift in decision-support architecture, moving beyond the static pattern recognition of traditional machine learning toward a dynamic, sequential decision-making framework. While standard predictive models excel at classifying historical data, Q-learning establishes an autonomous agent designed to achieve goal-oriented behavior through direct environmental interaction. This transition from prediction to action allows organizations to deploy systems that do not merely forecast outcomes but actively navigate complex processes to maximize long-term utility.

The technical core of this framework is the Q-value: an estimate of the cumulative long-term return expected from taking a specific action in a given state and following an optimal policy thereafter. The learning mechanism is fundamentally iterative. The agent typically begins with zero-initialized values and refines them through a continuous cycle of trial, feedback, and consequence. When an action yields a reward, the update rule shifts the current Q-value estimate toward that realized return. Through repeated transitions, the agent’s internal model converges toward the true expected return, mapping out a high-fidelity strategy for navigating the environment.

From a strategic standpoint, the advantage of learning from consequences is paramount. Unlike supervised learning, which requires massive, pre-labeled datasets that are often expensive or impossible to acquire, Q-learning discovers optimal strategies autonomously. That makes it a strong candidate for business problems where the correct answer is unknown and must be discovered through exploration. However, while the theoretical promise is significant, the transition to a production-ready system is governed by rigid architectural constraints that dictate feasibility.

2. Scalability analysis: the state–action space threshold

The viability of a Q-learning deployment is primarily determined by the state–action space explosion: the relationship between environmental complexity and the computational resources required to represent it. In a reinforcement learning context, the dimensions of the problem dictate whether a standard tabular approach can achieve a functional return on investment (ROI).

Tabular Q-learning requires the agent to maintain a literal lookup table containing every possible state–action pair. As the number of variables increases, the memory footprint and the data-collection requirements grow exponentially, leading to the curse of dimensionality.

Environment attribute	Tabular feasibility	Generalization capability	Infrastructure impact
Small / discrete spaces	High: ideal for well-defined, finite logic.	None: atomic lookups only; every state is new.	Minimal memory and compute overhead.
Large / continuous spaces	Low: computationally and logically infeasible.	None: no ability to infer value for unseen states.	Exponential state-space growth.

Beyond the state space, a critical feasibility hurdle lies in continuous action spaces. While continuous states are difficult, continuous actions require the agent to compute an argmax over an infinite set of possibilities, making standard Q-learning effectively a no-go without heavy discretization or an actor–critic architecture. The organizational “so what” is data-collection cost: in a high-dimensional space, the system may require millions of trials before it stops making costly mistakes in production. Without generalization, time-to-value is often delayed beyond the window of project viability, because the agent must visit every cell in its memory before it becomes reliable.

3. Input data evaluation: high dimensionality and function approximation

The format of organizational data—ranging from structured discrete values to high-dimensional visual streams—is a primary determinant of the required architecture. Tabular methods fail in many modern enterprise environments because they treat every unique configuration as a completely novel state, lacking the ability to identify similarities between nearly identical inputs.

To address this, we move to deep Q-networks (DQN), using function approximation as the technological bridge. Instead of a lookup table, a neural network acts as a regressor to estimate Q-values. Architecturally, this is significant because the network treats states as vectors of features rather than atomic identifiers. That allows interpolation: the agent can infer the value of a state it has never encountered based on its similarity to known feature patterns.

While deep variants provide the power to process raw images and complex sensory data, they introduce significant engineering complexity. Shifting to deep variants increases inference latency and necessitates more robust retraining pipelines. The move from recording results to approximating them means the system is now susceptible to the instabilities of neural network training, requiring a much higher level of oversight throughout the development lifecycle to ensure that predicted rewards align with physical or economic reality.

4. Environmental dynamics and policy stability

A foundational assumption in reinforcement learning is stationarity: the requirement that the environment’s transition rules and reward structures remain relatively constant. For a decision-support system to be mission-critical, the objective it is optimizing must be stable enough for the policy to converge.

In the real world, organizational dynamics are frequently non-stationary. If market conditions, consumer behavior, or operational rules shift, the algorithm finds itself chasing a moving target. When the underlying logic of the environment drifts, previously learned Q-values become legacy technical debt, potentially leading to a total collapse of the decision policy.

The strategic risk here is a combination of model drift and poor exploration. If the environment is volatile, the agent may never spend enough time in a stable regime to identify a useful policy. In a live business context, this produces brittle systems that yield inconsistent or suboptimal decisions. A policy that was optimal yesterday can become catastrophic today if reward signals have shifted, necessitating continuous monitoring and a retraining infrastructure to maintain operational stability.

5. Technical risk assessment: convergence and hyperparameters

Reinforcement learning systems are notoriously sensitive to technical configuration. Hyperparameters such as the learning rate (how aggressively new information replaces old estimates) and the discount factor (the valuation of future versus immediate rewards) serve as the steering mechanisms for the entire architecture.

Poor hyperparameter selection leads to critical operational failures:

Slow convergence: The agent consumes massive compute resources without reaching a functional policy, turning the project into a sunk cost.
Divergence: The learning process fails entirely, with Q-values fluctuating wildly and the policy never settling.

The most dangerous outcome is a silent failure: a system appears to be learning but is actually converging on a brittle, narrow policy that fails when faced with minor environmental stochasticity. That lack of robust convergence does not merely delay ROI; it introduces the risk of deploying a system that performs well in a simulator but breaks in the field, leading to unpredictable behavior in production.

6. Final decision matrix: tabular vs. deep Q-learning

To facilitate the go/no-go decision, stakeholders should evaluate the project against the following technical feasibility indicators.

Candidate for tabular Q-learning

Environments with small, discrete state and action spaces.
Highly stationary dynamics with static rules.
Low-dimensional, structured data inputs.

Candidate for deep Q-learning / advanced variants

High-complexity environments (large or continuous state spaces).
Visual or high-dimensional sensory inputs.
Use cases requiring generalization across similar but non-identical scenarios.

Infeasible scenarios

Highly non-stationary dynamics where rules change faster than the agent can learn.
Extreme exploration sensitivity: If the cost of a trial-and-error failure includes damaged physical assets, lost customers, or regulatory breaches, standard Q-learning is a no-go without a high-fidelity simulator.

Q-learning remains a vital mental model for understanding how systems learn from consequences. However, the move to production requires a rigorous upfront assessment of the state–action space and the cost of exploration. By addressing these architectural constraints early, organizations can mitigate technical debt and ensure that their decision systems provide a stable, long-term competitive advantage.

Beyond prediction: what the trial and error of Q-learning teaches us about intelligence

Most of our modern encounters with artificial intelligence are essentially transactional. We provide a prompt, and the system predicts the next word; we upload a photo, and the algorithm classifies the image. This is the world of supervised learning: a powerful, high-speed form of pattern recognition that maps static inputs to labeled outputs. While impressive, this prediction-first view of AI misses a vital dimension of true intelligence: the capacity for agency.

The most profound leap in machine learning occurs when we move from systems that merely know to systems that act. Intelligence, in its most naturalistic form, is not about memorizing a static map of the world; it is about navigating an environment and learning from the ripples of one’s own choices. This is the domain of Q-learning, a foundational reinforcement learning method that trades the safety of labeled answers for the messy, iterative reality of learning through consequence.

Takeaway 1: Learning from consequences, not labels

In the traditional AI paradigm, we serve as the system’s omniscient tutor, providing the correct answers via massive, labeled datasets. Q-learning discards this hierarchy, replacing the passive observer with an agent: an active participant locked in a continuous feedback loop with its environment. There are no predetermined labels here, only outcomes.

As defined in classic reinforcement learning theory, the agent learns which action is best in a given state by trying, receiving feedback, and improving over time.

This shift mirrors our own biological development. A child does not learn that a stove is hot because of a linguistic label; they learn through the immediate, visceral consequence of a physical interaction. By prioritizing environmental consequences over prepackaged answers, Q-learning offers a more organic mental model for intelligence—one in which correctness is not a property of the data, but a result of the agent’s goals and the environment’s physics.

Takeaway 2: The incremental logic of the Q-value

At the core of this adaptive behavior is the Q-value: a mathematical estimate of the long-term return an agent can expect by taking a specific action in a specific state. The brilliance of Q-learning, however, lies in its patience. It does not update its worldview based on a single flash of luck; it relies on a cautious, incremental update rule.

Consider a system where all Q-values are initialized at zero. If an agent takes an action that suddenly yields a reward of 5, a primitive system might immediately set that action’s value to 5. Q-learning is more sophisticated: it moves the estimate from 0 toward 5 by a small fraction. This fraction is the learning rate (α), a hyperparameter that dictates how much new information should override the old. This incrementalism is the physical manifestation of caution; it ensures the agent does not overreact to noise or outliers, building a stable, reliable average of experience over time rather than chasing every fleeting signal.

Takeaway 3: The curse of dimensionality and the limits of memory

Despite its conceptual elegance, classic Q-learning is often a victim of its own precision, drowning in the very data it seeks to organize. In its most basic form—tabular Q-learning—the algorithm requires a dedicated entry for every possible state–action pair. Imagine a massive ledger where every potential move in every potential situation is recorded.

As an environment moves from a simple grid to the complexity of the real world, the number of required entries explodes, making the table infeasible to maintain. This is the curse of dimensionality. It is a humbling irony of AI research: a mathematically sound algorithm can be rendered useless by the sheer volume of raw data. This limitation eventually necessitated the move from simple tables to deep Q-networks, where neural networks act as function approximators to estimate values for states the agent has never seen.

Takeaway 4: The high cost of staying safe (the exploration paradox)

A successful Q-learning agent requires strong exploration. If an agent is too conservative, repeating only the paths it already knows to be safe, it risks the tragedy of a suboptimal policy. It becomes an entity that is good enough but never truly great, trapped at a local peak because it was too afraid to descend into the valley of the unknown.

This reveals the inherent cost of intelligence. To eventually identify the best moves, an AI must be willing to make deliberately suboptimal ones. It must risk immediate failure to gather the long-term data necessary to refine its internal Q-values. Exploration is not a distraction from the goal; it is the price of admission for finding a better path. An agent that never risks mediocrity can never achieve mastery.

Takeaway 5: Chasing a moving target

Even with sound exploration, Q-learning remains a delicate balancing act. It is notoriously sensitive to hyperparameters such as the learning rate and the discount factor (which determines how much the agent weighs future rewards versus immediate ones). If the rules of the environment shift—a phenomenon known as non-stationary dynamics—the agent finds itself chasing a moving target, where hard-won knowledge is rendered obsolete by a changing world.

Furthermore, when we move beyond simple tables and use function approximation to handle continuous spaces, the problem can become fundamentally ill-posed. Because the agent is updating its estimates based on other estimates, the logic can become circular and unstable. Without meticulous tuning, the agent’s intelligence can collapse, leading to divergence rather than a stable policy.

Conclusion: The enduring power of the mental model

Despite the challenges of scaling and the sensitivity of its parameters, Q-learning remains the essential bedrock of sequential decision-making. It stripped away the opacity of modern neural networks to reveal the core engine of reinforcement learning: the iterative refinement of value through experience. It is the direct ancestor of the deep Q-networks that conquered Atari games and of the sophisticated algorithms currently powering modern robotics.

As we stand on the precipice of more autonomous and adaptive AI, we might look inward. How much of what we call human expertise—the intuition of a grandmaster or the split-second reaction of a pilot—is simply a high-level version of Q-learning? Perhaps our lives are just a vast, continuous update of our own internal Q-values, refined through a lifetime of trial and error.

References

These sources ground the technical claims above: core definitions, where tabular and value-based methods break down, stability of Q-learning with function approximation, and practical guidance for deep Q-networks in real pipelines.

Q-learning. Wikipedia. Overview of the algorithm, the Bellman backup, and the tabular setting.
Limitations of value-based methods. ApX Machine Learning (intermediate RL course). Why argmax-based value methods struggle with continuous actions and high-dimensional spaces—directly tied to the feasibility discussion in §2–§3.
Is Q-learning an ill-posed problem?. arXiv (HTML version). Formal perspective on instability when Q-learning uses function approximation and bootstraps from its own estimates—supporting the cautions in §3 and Takeaway 5.
Practical tips for training deep Q networks. Anyscale. Engineering-focused notes on hyperparameters, training stability, and operational pitfalls when moving from tabular Q-learning to DQNs—aligned with §5 and production readiness.
Three fundamental flaws in common reinforcement learning algorithms (and how to fix them). Towards Data Science. Accessible treatment of exploration, instability, and related failure modes in widely used RL methods, complementing the risk framing in §4–§6.

Syntactic Fluency, Semantic Fragility: Why AI Masters Form but Stumbles on Meaning

contact@corebaseit.com (Vincent Bevia) — Sun, 12 Apr 2026 10:00:00 +0100

Your favourite AI can compose a flawless sonnet, generate syntactically perfect ISO 8583 messages, and produce compilable C++ on the first attempt. Ask it whether that ISO message actually makes business sense, and you may get a confident, well-structured, beautifully formatted hallucination.

That asymmetry — syntactic excellence, semantic fragility — is not a bug that will be patched in the next release. It is a structural property of how these models work. Understanding it is the difference between using AI effectively and trusting output that looks right but isn’t.

The Syntax-Semantics Divide

Two terms that even experienced engineers conflate. Syntax asks: is this artefact well-formed according to the rules of its language? Semantics asks the harder question: given that it is well-formed, does it mean something valid in this context?

The distinction is universal. In natural language, “Colourless green ideas sleep furiously” is syntactically flawless English — Chomsky’s famous example — but semantically nonsensical. In code, int x = "hello"; may parse in some grammars but violates type rules. In payments, an ISO 8583 authorisation request can have every field correctly encoded in BCD and length-prefixed, yet carry an impossible combination of processing code and merchant category — syntactically perfect, semantically absurd.

Keep that payments example in mind. We’ll return to it.

Where Models Excel: The Syntax Engine

Large Language Models are statistical pattern machines trained on trillions of tokens. That architecture makes them extraordinary syntax engines. They internalise the distributional regularities of language, code, and structured data at a scale no human could match.

Grammar and natural language. Modern LLMs almost never produce ungrammatical English, Spanish, or Mandarin. Subject-verb agreement, tense consistency, pronoun resolution — these are solved problems for frontier models. The syntactic error rate in generated prose is vanishingly small, often lower than that of hurried human writers. This is not understanding; it is extremely refined pattern matching. But the results are indistinguishable in practice.

Code generation. Ask a model to scaffold a REST API in Python, Java, or Rust and the output will almost certainly compile or pass a linter on the first attempt. Bracket matching, indentation, import ordering, type annotations — the surface-level structure is handled with remarkable precision. Models have effectively memorised the formal grammars of dozens of programming languages.

Structured data. JSON, XML, YAML, Protocol Buffers, even ISO 8583 field layouts — models reproduce these structures faithfully. They know that a JSON object needs matching braces, that XML demands closing tags, that a bitmap in an ISO 8583 message is 64 bits representing which data elements follow. The form is rarely wrong.

Where Models Quietly Fail: The Semantics Gap

Syntax is necessary but never sufficient. A programme that compiles is not necessarily correct. A sentence that parses is not necessarily true. And this is precisely where the cracks appear.

Hallucination: Fluent Nonsense

The flagship semantic failure of LLMs is hallucination — generating statements that are syntactically perfect but factually wrong or logically incoherent. A model can write “The Treaty of Westphalia was signed in 1748 by Napoleon III” with the same confident cadence it uses for accurate history. The sentence is well-formed. It is also complete fiction. The model has no mechanism to verify truth against a grounded world model; it predicts the next plausible token, not the next true one. Ji et al.’s comprehensive survey of hallucination in NLG systems documents this across summarisation, dialogue, question answering, and translation — the problem is pervasive, not anecdotal.

Logical Consistency Under Pressure

Give a model a chain of logical constraints and ask it to maintain them across a long output and you will find the seams. In software architecture, this manifests as a model that produces a beautiful class diagram but introduces circular dependencies. In legal drafting, it writes clauses that individually look correct but collectively contradict each other. The local syntax is perfect; the global semantics are broken.

Domain Constraint Violations

This is the failure mode that matters most to engineers. Domain semantics are the rules that cannot be inferred from syntax alone — they require knowledge of the business, the physics, or the regulation. No amount of syntactic fluency can compensate for the absence of domain grounding.

The ISO 8583 Thought Experiment

Let me make this concrete with a domain I know well. Consider a model asked to generate a sample ISO 8583 authorisation request:

Field	Description	Value
MTI	Message Type	0100 (Authorisation Request)
DE 2	PAN	4111111111111111
DE 3	Processing Code	000000 (Purchase)
DE 4	Amount	000000010000 ($100.00)
DE 14	Card Expiry	2612
DE 18	Merchant Category	5999 (Misc. Retail)
DE 22	POS Entry Mode	051 (Chip read)
DE 25	POS Condition Code	08 (Mail/Phone Order)
DE 41	Terminal ID	TERM0001
DE 42	Merchant ID	MERCHANT0000001
DE 55	EMV Data (ICC)	(TLV-encoded chip data)

Every field is correctly formatted. The MTI is a valid four-digit code. The PAN passes Luhn. The processing code is a legitimate purchase indicator. The BCD encoding would be flawless. Syntactically, this message is impeccable.

Semantically, it is impossible.

Look at DE 22, DE 25, and DE 55 together. DE 22 says chip read — the card was physically inserted into a terminal. DE 55 contains EMV ICC data, confirming a chip interaction. But DE 25 says mail/phone order — a card-not-present transaction where no physical terminal is involved. You cannot simultaneously read a chip and conduct a mail-order transaction. Any payment processor’s validation engine would reject this message instantly. Any experienced payments engineer would catch it in seconds.

The model didn’t catch it because it doesn’t know what these fields mean in relation to each other. It knows what values are syntactically valid for each field independently. It does not understand the semantic contract between them — the domain invariant that says: if DE 22 indicates chip-read, then DE 25 cannot indicate card-not-present.

This is the syntax-semantics gap in action. Domain semantics are relational constraints that span multiple fields, layers, or concepts. Models excel at local correctness — each field in isolation — but struggle with global coherence — the fields together.

The Pattern Repeats Across Every Domain

The ISO 8583 example is specific to payments, but the structural problem is universal. Every domain with rich semantic constraints faces the same risk.

Medicine. A model generates a syntactically perfect prescription: drug name, dosage, frequency, route of administration — all individually valid. But the combination is a known lethal drug interaction. The form is right; the meaning could kill.

Legal contracts. Generated clauses that individually look correct but collectively create contradictory obligations. The indemnification clause in Section 4 conflicts with the liability cap in Section 7. Each section reads perfectly. Together they are unenforceable.

Infrastructure as code. A Terraform configuration that is syntactically valid HCL, passes terraform validate, and even terraform plan — but opens port 22 to 0.0.0.0/0 on a production database. The deployment tool sees correct syntax. The security team sees a catastrophe.

The common thread: syntactic validity provides no guarantee of semantic correctness. The gap exists in every domain where rules are relational, contextual, or normative rather than purely structural.

The Searle Parallel: Syntax Was Never Enough

Philosopher John Searle argued this point decades ago through his Chinese Room thought experiment. A person in a room follows rules to manipulate Chinese characters. They produce perfectly formed Chinese responses without understanding a single word. The room passes any syntactic test; it fails every semantic one.

LLMs are, in a very real sense, the most sophisticated Chinese Rooms ever built. They manipulate tokens according to learned statistical patterns with extraordinary fidelity. The patterns are so good that the output appears to understand. And often, for practical purposes, that appearance is sufficient. But when domain semantics demand genuine constraint satisfaction — when the relationship between fields, clauses, or concepts must be logically valid and not merely statistically plausible — the room’s walls become visible.

Bender and Koller formalised this intuition for the modern ML context in their ACL 2020 best paper: a system trained only on linguistic form cannot in principle learn meaning. The distributional signal in text encodes co-occurrence patterns, not the grounded relationships those patterns refer to. This doesn’t make the models useless — far from it — but it does explain why their failure mode is consistently semantic rather than syntactic.

Bridging the Gap: What We Can Do Today

This is not a counsel of despair. The syntax-semantics gap is real but manageable. Here is how experienced engineers are already working around it.

Structured validation layers. Use the model for generation, then pass output through domain-specific validators. In payments, that means running generated messages through your scheme’s validation engine. In code, that means static analysis, type checking, and property-based testing. The model drafts; the validator verifies.

Semantic guardrails in the prompt. Explicitly state domain invariants in the system prompt. “DE 25 must be consistent with DE 22” is a constraint the model can often respect when told — but will happily violate when not. This is the prompt engineering principle I’ve written about before: treat prompts as configuration contracts, not chat messages.

Human-in-the-loop for critical domains. Treat model output as a first draft, never a final artefact, in domains where semantic errors carry real consequences. The model drafts; the domain expert validates. This is the amplifier model — AI scales what you bring to the table, but you need to bring something to the table.

Retrieval-Augmented Generation (RAG). Ground the model in authoritative domain documentation. If the ISO 8583 specification is in the retrieval index, the model is far less likely to produce impossible field combinations. RAG doesn’t eliminate semantic errors, but it narrows the gap substantially by giving the model access to the constraints it would otherwise lack.

Fine-tuning on domain corpora. Expose the model to thousands of validated, semantically correct transactions (or contracts, or prescriptions) so it absorbs domain constraints statistically, even if it never truly “understands” them. This shifts the probability distribution toward correctness without guaranteeing it.

Will the Gap Close?

Frontier models are improving at semantic tasks. Chain-of-thought reasoning, tool use, and long-context architectures are pushing the boundary. But there are structural reasons to believe a gap will persist.

Statistical plausibility is not logical necessity. Training data encodes what was, not what must be. Domain constraints are normative, not descriptive — the ISO 8583 spec defines what shall be valid, not just what has historically appeared in message logs. A model trained on text cannot reliably distinguish between the two.

Grounding remains absent. What a chip reader actually does, what a drug interaction actually causes, what an open port actually exposes — these are facts about the physical world that text-only training cannot capture. Multimodal and tool-augmented systems are beginning to address this, but the gap between reading about something and knowing what it does is not trivial to close.

Edge cases are adversarial. The long tail of domain semantics — the unusual field combinations, the regulatory exceptions, the rarely-triggered invariants — is precisely where models are weakest. These cases are underrepresented in training data and overrepresented in production failures.

Models will get better at semantics. But syntactic fluency will likely remain ahead of semantic reliability for the foreseeable future. That asymmetry has profound implications for how we architect systems that incorporate AI.

The Engineer’s Takeaway

Trust the syntax. Verify the semantics. Always.

AI models are the most powerful syntactic engines humanity has ever built. They produce well-formed text, code, and structured data with a fluency that is genuinely impressive. But fluency is not understanding. Form is not meaning. A perfectly formatted ISO 8583 message that violates domain invariants is not a valid transaction — it is a beautifully dressed lie.

As engineers, our job has always been to ensure that systems are not just well-formed but correct. In the age of AI, that responsibility doesn’t diminish. It sharpens. The model handles the syntax so you can focus on what it cannot yet do reliably: ensuring that the output means what it should.

That is not a limitation to lament. It is a division of labour to embrace.

References

Searle, J. R. (1980). “Minds, brains, and programs.” Behavioral and Brain Sciences, 3(3), 417-424. cambridge.org
Bender, E. M., & Koller, A. (2020). “Climbing towards NLU: On Meaning, Form, and Understanding in the Age of Data.” Proceedings of ACL 2020, 5185-5198. aclanthology.org/2020.acl-main.463
Ji, Z., Lee, N., Frieske, R., et al. (2023). “Survey of Hallucination in Natural Language Generation.” ACM Computing Surveys, 55, Article 248. arxiv.org/abs/2202.03629
Chomsky, N. (1957). Syntactic Structures. Mouton & Co. — the “Colourless green ideas sleep furiously” example
ISO 8583 — Financial transaction card originated messages — Interchange message specifications
Point-of-Sale Systems Architecture — Volume 1: A Practical Guide to Secure, Certifiable POS Systems — broader context for ISO 8583 and EMV in production systems
The Obsolescence Paradox: Why the Best Engineers Will Thrive in the AI Era — engineering perspective on AI adoption
AI as an Amplifier, Not a Replacement — related post on why domain expertise is the multiplier
Prompt Engineering for POS — companion post on treating LLM inputs as architecture

CAPKs: The Cryptographic Trust Anchors Behind Every EMV Transaction

contact@corebaseit.com (Vincent Bevia) — Thu, 09 Apr 2026 08:00:00 +0100

When a cardholder taps a phone or inserts a chip card, the POS terminal does not simply read data and forward it to the network. Before the authorization request is constructed, before cardholder verification is performed, the terminal must cryptographically verify the authenticity of the payment instrument. This verification happens locally — inside the terminal itself — often before the issuing bank is even aware a transaction has started.

The mechanism that makes this possible is a set of cryptographic primitives called Certification Authority Public Keys (CAPKs). They are the root of the trust chain that underpins EMV’s Offline Data Authentication framework. Without them, a terminal cannot distinguish a legitimate chip card from a counterfeit, and the entire EMV security model collapses at the point of interaction.

This post explains what CAPKs are, how they function within the EMV cryptographic hierarchy, why they fail in the field, and what engineers, solutions architects, and terminal fleet operators need to understand to manage them correctly.

The concepts discussed here complement the EMV security material in POINT OF SALE ARCHITECTURE — Volume 1: A Practical Guide to Secure, Certifiable POS Systems (the book), which provides the broader context for how CAPKs fit into end-to-end card-present security.

The Problem CAPKs Solve

Consider the security challenge from the terminal’s perspective. A card is presented. The terminal reads data from the chip: the PAN, expiry date, application data, issuer-specific parameters. But how does the terminal know this data is legitimate? How does it know the card was actually issued by Visa, Mastercard, or any other scheme — and not fabricated by an attacker who loaded fraudulent data onto a blank chip?

The terminal cannot ask the issuer in real time. Offline Data Authentication must happen before the online authorization request is built. The terminal needs a mechanism to verify the card’s identity using only the information it already possesses locally.

CAPKs are that mechanism. They are the public keys of the Certification Authorities (the card schemes themselves — Visa, Mastercard, Amex, JCB, Discover, UnionPay) that sit at the top of a three-level RSA key hierarchy. The terminal uses these keys to validate a chain of certificates that ultimately proves the card’s data is authentic and has not been tampered with.

The EMV Public Key Hierarchy

EMV card authentication relies on a three-tier RSA public key infrastructure. Each level in the hierarchy certifies the level below it, forming a chain of trust that begins with the Certification Authority and terminates at the individual card.

Level 1: Certification Authority (CA)

At the top of the hierarchy sits the Certification Authority — the card scheme itself (e.g., Visa, Mastercard). The CA holds a private key that is used to sign Issuer Public Key Certificates. The corresponding public key — the CAPK — is distributed to terminals so they can verify those certificates.

The CA private key is one of the most sensitive assets in the payment ecosystem. It never leaves the scheme’s secure infrastructure. Only the public component is distributed to terminals.

Level 2: Issuer

Each card issuer (the bank that issued the card) has its own RSA key pair. The issuer’s public key is signed by the CA using the CA’s private key, producing an Issuer Public Key Certificate. This certificate is stored on the card itself.

When the terminal reads this certificate from the card, it uses the CAPK to verify the CA’s signature. If the signature is valid, the terminal can trust that the issuer’s public key is genuine.

Level 3: ICC (Integrated Circuit Card)

For Dynamic Data Authentication (DDA) and Combined DDA (CDA), the card itself has its own RSA key pair. The card’s public key is signed by the issuer, producing an ICC Public Key Certificate — also stored on the card.

The terminal verifies this certificate using the issuer’s public key (which it has already validated in the previous step). If valid, the terminal trusts the card’s public key and can verify dynamic signatures generated by the card in real time.

The full chain looks like this:

┌─────────────────────────────────┐
│ Certification Authority (CA) │
│ CAPK stored in terminal │
│ Private key held by scheme │
└──────────────┬──────────────────┘
 │ Signs
 ▼
┌─────────────────────────────────┐
│ Issuer Public Key │
│ Certificate stored on card │
│ Verified using CAPK │
└──────────────┬──────────────────┘
 │ Signs
 ▼
┌─────────────────────────────────┐
│ ICC Public Key │
│ Certificate stored on card │
│ Verified using Issuer PK │
└─────────────────────────────────┘

If any link in this chain is broken — if the CAPK is missing, expired, or misconfigured — the terminal cannot complete the verification, and authentication fails.

Anatomy of a CAPK

A CAPK is not a simple password or a single string. It is a multi-component RSA public key structure, and every component must be correctly provisioned for the key to function. The five required elements are:

RID (Registered Application Provider Identifier)

A 5-byte identifier that designates the card scheme. The RID tells the terminal which payment network the key belongs to:

RID	Scheme
A000000003	Visa
A000000004	Mastercard
A000000025	American Express
A000000065	JCB
A000000152	Discover
A000000333	UnionPay

CAPK Index (PKI)

A 1-byte index that identifies which specific public key within a given scheme should be used. A single scheme may have multiple active CAPKs at any time — different key sizes, different validity periods, different purposes. The index allows the terminal to select the correct key based on what the card requests.

For example, Visa might have index 09 (a 1408-bit key for production) and index 92 (a test key for certification environments). The card signals which index to use during the transaction.

Modulus

The modulus is the large integer $n$ that forms the core of the RSA public key. In payment contexts, modulus sizes typically range from 1024 to 2048 bits, depending on the scheme and the key generation date. The modulus, combined with the exponent, is what allows the terminal to perform the RSA signature verification.

$$n = p \times q$$

Where $p$ and $q$ are the large prime factors known only to the CA.

Exponent

The public exponent $e$ used in the RSA verification. In EMV, the exponent is typically either 3 or 65537 ($2^{16}+1$). The exponent 3 is computationally efficient but provides a smaller security margin; 65537 is the industry standard for stronger security:

$$\text{Signature verification: } m = s^e \mod n$$

Checksum (Hash)

A SHA-1 hash computed over the concatenation of the RID, PKI, Modulus, and Exponent. The terminal uses this checksum to verify that the CAPK data stored in its memory has not been corrupted or tampered with. Before using any CAPK for a cryptographic operation, the terminal must recompute the hash and compare it against the stored checksum.

If the checksum fails, the key must not be used — even if all other components appear correct. This is the terminal’s self-integrity check.

Offline Data Authentication: Where CAPKs Do Their Work

CAPKs are the enabling mechanism for EMV’s Offline Data Authentication (ODA) — the process by which a terminal verifies the authenticity of a card’s data without contacting the issuer. ODA is not optional. It is a foundational step in the EMV transaction flow, executed before cardholder verification and before terminal risk management.

A common misconception — even among experienced payment engineers — is that ODA only matters for offline transactions. This is incorrect. ODA is performed on every EMV transaction, whether the transaction will ultimately go online for authorization or not. The purpose of ODA is to establish that the card is genuine at the point of interaction. The online authorization (ARQC verification by the issuer) is a separate and complementary mechanism that operates at the network level.

EMV defines three ODA methods, each building on the previous:

Static Data Authentication (SDA)

SDA is the simplest and weakest form. During card personalization, the issuer signs a block of static card data (PAN, expiry, application data) using the issuer’s private key. This signature is stored on the card.

At the terminal, the verification flow is:

Recover the Issuer Public Key: The terminal reads the Issuer Public Key Certificate from the card and decrypts it using the CAPK. If the recovered data is valid and the hash matches, the issuer’s public key is trusted.
Verify the Signed Static Application Data: The terminal uses the issuer’s public key to verify the signature over the card’s static data. If the signature is valid, the data has not been tampered with since personalization.

SDA proves data integrity but not card uniqueness. A perfect copy of the card data — including the signature — would pass SDA on any terminal. For this reason, SDA is considered legacy and is no longer accepted in most modern deployment profiles.

Dynamic Data Authentication (DDA)

DDA addresses SDA’s cloning vulnerability by requiring the card to prove it possesses a unique private key. The flow adds a third level:

Recover the Issuer Public Key using the CAPK (same as SDA).
Recover the ICC Public Key: The terminal reads the ICC Public Key Certificate from the card and verifies it using the issuer’s public key.
Verify a Dynamic Signature: The terminal sends the card a challenge (an unpredictable number). The card signs this challenge using its private key. The terminal verifies the signature using the ICC public key.

Because the challenge is different for every transaction, the signature cannot be replayed. A cloned card that does not possess the genuine ICC private key cannot produce a valid dynamic signature. DDA proves both data integrity and card authenticity.

Combined DDA with Application Cryptogram (CDA)

CDA integrates dynamic authentication into the GENERATE AC command. Instead of performing DDA as a separate step, the card signs the Application Cryptogram (ARQC or TC) together with dynamic authentication data in a single cryptographic operation.

This is the strongest ODA method because it binds the card authentication to the specific transaction outcome. An attacker cannot substitute a pre-computed cryptogram from one transaction into another — the dynamic signature covers both the authentication proof and the transaction-specific data.

CDA is the standard for modern EMV deployments and is required by most scheme mandates for new card issuance.

When CAPKs Fail: The Silent Terminal Failure

One of the most operationally damaging failure modes in card-present payments is a CAPK-related silent failure. The terminal is powered on. The network connection is healthy. The POS application is running. And yet transactions decline.

This happens because the terminal cannot perform ODA without the correct CAPK. If the key is missing, expired, or corrupted, the authentication chain is broken at its root. The failure cascades:

The terminal cannot recover the issuer’s public key from the certificate on the card.
SDA, DDA, or CDA fails.
The Terminal Verification Results (TVR) register the authentication failure.
Terminal risk management triggers. Depending on the terminal’s configuration and the card’s risk parameters, the outcome is one of:
- Transaction declined at the terminal level (no authorization attempt).
- Force online — the terminal overrides the offline decline and attempts an online authorization. This may succeed if the issuer approves, but it adds latency, increases network load, and defeats the purpose of offline authentication.
- Fallback — in some configurations, the terminal may attempt a magstripe fallback, which introduces its own security and liability risks.

From a Solutions Architect’s perspective, this is a critical deployment risk. A fleet of terminals with stale or incomplete CAPK sets will produce intermittent, hard-to-diagnose transaction failures. The symptoms look like network issues, host timeouts, or card defects — but the root cause is a misconfigured trust anchor inside the terminal itself.

Common Causes of CAPK Failure

Cause	Description
Missing CAPK	The terminal was never provisioned with the key for a given scheme/index combination
Expired CAPK	The key has passed its validity period and the terminal correctly refuses to use it
Checksum mismatch	The CAPK data was corrupted during provisioning or storage — the terminal’s integrity check fails
Wrong environment	Test CAPKs loaded on production terminals, or production CAPKs loaded on test terminals
Incomplete rotation	A new CAPK was distributed by the scheme, but the terminal fleet was not updated

CAPK Lifecycle Management

CAPKs are not static configuration. They have a defined lifecycle that must be actively managed across the entire terminal fleet.

Key Distribution

CAPKs are distributed by the card schemes to acquirers, payment processors, and terminal vendors. The distribution typically occurs through secure channels — scheme portals, encrypted key files, or direct integration with Terminal Management Systems (TMS). The keys are public (they are RSA public keys, after all), but the integrity of the distribution matters: a tampered CAPK would allow an attacker to forge issuer certificates.

Key Rotation

Card schemes periodically retire old CAPKs and introduce new ones. This happens for several reasons:

Key size upgrades: As computational power increases, smaller RSA key sizes become vulnerable. Schemes have migrated from 1024-bit to 1408-bit to 1984-bit and 2048-bit keys over time.
Certificate expiration: Each CAPK has an expiration date. Cards issued near the end of a key’s validity period may still be in circulation after the key expires, creating a window where terminals must support both old and new keys.
Specification updates: New EMV specification versions may require updated key parameters.
Compromise response: If a CA private key were ever compromised (an extremely rare event), all associated CAPKs would need to be revoked and replaced across the global terminal fleet.

Fleet-Wide Updates

For a large merchant or acquirer, CAPK rotation is a fleet management operation. Every terminal in the field must receive the updated key set, and the update must be verified. A TMS typically handles this through scheduled configuration pushes, but the reliability of the process depends on:

Terminal connectivity (terminals that are offline for extended periods may miss updates)
TMS configuration integrity (a misconfigured TMS can propagate bad keys across thousands of terminals)
Rollback procedures (if a bad key set is pushed, can it be reverted without field visits?)

This operational reality is why EMV compliance mandates are explicit about key management:

“Technicians and developers should ensure these keys are accurately configured, regularly updated, and securely managed to maintain the integrity of the EMV transaction process.”

CAPKs and the Broader EMV Security Architecture

CAPKs do not operate in isolation. They are one component of a layered security architecture that includes multiple complementary mechanisms:

Security Layer	Mechanism	What It Proves
Card Authentication (ODA)	CAPKs → Issuer PK → ICC PK	The card is genuine and the data is intact
Transaction Authentication	ARQC / ARPC	The transaction is unique and verified by the issuer
Cardholder Verification	PIN (online/offline), CVM	The person presenting the card is the legitimate cardholder
Data Encryption	DUKPT / TDES / AES	Transaction data is protected in transit
Key Management	HSM, TMS, key injection	Cryptographic material is securely provisioned and maintained

ODA (powered by CAPKs) answers the first question in the security chain: Is this card real? Only after that question is answered does the terminal proceed to the subsequent questions: Is this person authorized to use the card? Should this transaction be approved?

If ODA fails, the remaining layers can still function — the transaction might go online and the issuer might approve it based on ARQC verification alone. But the terminal has lost its ability to independently assess the card’s legitimacy, which weakens the overall security posture and shifts risk toward the acquirer and merchant.

Implementation Considerations

For Terminal Developers

Validate the checksum before every use. Never assume a CAPK in memory is intact. Recompute the SHA-1 hash and compare it against the stored checksum before performing any RSA operation with the key.
Support multiple active keys per scheme. Terminals must be able to hold multiple CAPKs for the same RID, differentiated by the PKI. During key rotation periods, both the old and new keys must be available.
Handle missing keys gracefully. If the required CAPK is not present, set the appropriate TVR bit and proceed to terminal risk management. Do not crash, hang, or produce ambiguous error messages.
Log CAPK-related failures. Include the RID and PKI in diagnostic logs so that field support teams can quickly identify which key is missing or invalid.

For Solutions Architects and Fleet Operators

Treat CAPK provisioning as a deployment gate. A terminal is not ready for production until its CAPK set has been verified against the current scheme requirements.
Monitor CAPK expiration dates. Build alerting into the TMS or fleet management platform that flags terminals with CAPKs approaching expiration.
Test with scheme-specific certification CAPKs. EMV certification environments use dedicated test CAPKs. Never use production keys in a certification lab, and never deploy test keys to production terminals.
Maintain a CAPK inventory. Track which key versions are deployed across the fleet, and ensure consistency after every TMS push.

For Acquirers and Processors

Coordinate with schemes on key rotation schedules. Schemes announce CAPK changes in advance through technical bulletins. Build these into your operational calendar.
Validate CAPK sets during terminal onboarding. When a new terminal or terminal application is brought into the acquiring environment, verify the CAPK set before allowing live transactions.

Summary

The CAPK is the cryptographic root of trust in the EMV card-present ecosystem. It enables the terminal to independently verify that a payment instrument is genuine — without relying on an external network connection or the issuing bank.

The key points:

CAPKs are not just for offline transactions. They enable Offline Data Authentication on every EMV transaction, providing a foundational layer of security that operates independently of the online authorization.
The trust chain is fragile. A missing or misconfigured CAPK breaks authentication at its root, producing silent terminal failures that are difficult to diagnose and operationally damaging.
A CAPK is a multi-component cryptographic object. Five elements — RID, PKI, Exponent, Modulus, and Checksum — must be precisely aligned for the key to function.
Lifecycle management is a compliance mandate. CAPKs must be actively distributed, monitored, rotated, and verified across the terminal fleet. Treating them as static configuration is how avoidable field failures happen.

In payments, the infrastructure that works best is the infrastructure nobody notices. CAPKs are the invisible foundation that makes EMV work. Understanding them is not optional for anyone building, operating, or certifying card-present payment systems.

What Actually Happens in the 2–3 Seconds of a Card Payment

contact@corebaseit.com (Vincent Bevia) — Sun, 05 Apr 2026 08:00:00 +0100

Most people experience a card transaction as a single gesture — tap, beep, approved. What they don’t see is that those 2–3 seconds compress one of the most tightly orchestrated distributed systems in modern commerce: cryptographic authentication, cardholder verification, terminal-side risk management, network routing across multiple financial institutions, real-time issuer decisioning, and a response that travels back through the entire chain before the terminal displays a result.

Every stage has a purpose. Every stage can fail. And if you’re building, certifying, or operating POS systems, understanding what happens in those seconds — and why — is not optional. This post walks through the full lifecycle of a card-present transaction, from the moment the card is presented to the moment the terminal shows “Approved.”

Transaction Initialization: The Terminal and Card Negotiate Trust

The transaction begins the moment a card is presented to the terminal — whether by contactless tap (NFC), chip insertion (ICC), or magnetic stripe swipe. In EMV-based flows, which dominate globally, this first phase is not passive card reading. It is a structured negotiation between two computing devices.

The terminal first detects the interface — contact or contactless — and initiates application selection. The card may support multiple payment applications (Visa credit, Mastercard debit, a domestic scheme), and the terminal selects the appropriate one using the Application Identifier (AID). This selection follows priority rules defined by the terminal configuration, the card’s Application Priority Indicator, and scheme-specific kernel logic. For contactless, the Entry Point specification governs which kernel is activated and how the card is processed.

Once the application is selected, the terminal reads the card’s critical data: the PAN, expiry date, application usage controls, issuer-defined parameters, and the card’s cryptographic capabilities. It also establishes the transaction context — amount, currency, terminal type, terminal capabilities, country code — that will feed into every subsequent decision.

This is the foundation. Everything that follows — authentication, verification, risk analysis, cryptogram generation — depends on the data exchanged in this phase. A misconfigured terminal that reads the wrong tags, selects the wrong application, or misreports its own capabilities will produce downstream failures that are difficult to diagnose.

Card Authentication: Is This Card Genuine?

Before the terminal trusts any data from the card, it needs to establish that the card itself is authentic — that it was legitimately issued and has not been tampered with.

EMV provides three mechanisms for this, in ascending order of strength:

Static Data Authentication (SDA) verifies that the card’s static data (PAN, expiry, issuer-defined data) was signed by the issuer at personalization time. The terminal validates the signature using the issuer’s public key, recovered through the CA public key hierarchy. SDA proves the data has not been altered, but it does not prove uniqueness — a perfect copy of the signed data would pass the same check. SDA is legacy and no longer sufficient for most deployment profiles.

Dynamic Data Authentication (DDA) goes further. The card generates a dynamic signature using its own private key, over data that includes a terminal-generated unpredictable number. The terminal verifies this signature using the card’s ICC public key. Because the signature includes a random challenge, it cannot be replayed or predicted. DDA proves the card possesses a unique private key — which means the card is genuine, not a clone.

Combined DDA with Application Cryptogram (CDA) integrates the dynamic authentication into the cryptogram generation step itself. The card signs the Application Cryptogram (ARQC or TC) together with dynamic data, combining card authentication and transaction authorization into a single cryptographic operation. CDA is the strongest mechanism and is the standard for modern EMV deployments.

The question this phase answers is precise: Is this card a legitimate instrument issued by a real issuer, and can it prove it? Everything downstream — CVM, risk management, authorization — depends on this answer being correct.

Cardholder Verification: Who Is Holding the Card?

Card authentication proves the instrument is genuine. It does not prove the person presenting it is the legitimate cardholder. That is a separate problem, and it is solved by Cardholder Verification Methods (CVM).

The issuer encodes a CVM strategy in the card’s CVM List (tag 8E) — a prioritized list of verification methods and the conditions under which each applies. The terminal walks the list and selects the first method that both parties support and whose condition is satisfied for the current transaction context.

The primary methods:

Online PIN — The cardholder enters their PIN on a PCI-certified PIN Entry Device (PED). The PED encrypts the PIN block immediately — the clear PIN never exists outside the secure hardware. The encrypted PIN block travels through the acquirer to the issuer, where an HSM decrypts and validates it. This is the strongest widely deployed CVM for card-based transactions.

Offline PIN — The card itself verifies the PIN using a reference value stored in secure chip memory. A PIN Try Counter (tag 9F17) limits brute-force attempts at the hardware level. Offline PIN is essential for environments where the terminal cannot always reach the issuer — fuel, transit, rural acceptance, resilience-first architectures. The issuer never sees the PIN; it trusts the chip’s verification result.

Consumer Device CVM (CDCVM) — For mobile wallet transactions (Apple Pay, Google Pay), the cardholder authenticates on the device using biometrics or a device passcode. The wallet cryptogram includes a flag indicating CDCVM was performed. This satisfies the same architectural requirement — strong cardholder verification — with a different interface.

Signature — A human-compared mark with no cryptographic binding to the cardholder. Largely deprecated but still present in some legacy configurations.

No CVM — Used for low-value contactless transactions where the scheme has determined the risk is bounded by the transaction amount and cumulative limits. This is an intentional risk trade-off, not an absence of security.

A critical distinction that is often misunderstood: EMV authenticates the card. CVM authenticates the cardholder. These are two different security problems solved by two different mechanisms in the same flow. Conflating them — treating chip authentication as if it also proves cardholder identity — leads to gaps in the risk model.

Terminal and Card Risk Management: Decisions at the Edge

Before the transaction goes online to the issuer, both the terminal and the card perform independent risk assessments. This is one of the most underappreciated phases of the EMV flow — and one of the most architecturally significant.

Terminal Risk Management

The terminal evaluates the transaction against its own configured rules:

Floor limit checking. Is the transaction amount above the terminal’s floor limit? If so, the transaction must go online for issuer authorization regardless of other factors.
Random transaction selection. Even below the floor limit, a configurable percentage of transactions are randomly selected for online authorization. This prevents a pattern where low-value fraud always stays offline and undetected.
Velocity checking. The terminal can track consecutive offline transactions and force an online authorization after a threshold is reached. This bounds the exposure from cards that have been operating offline for extended periods.

Card Risk Management

The card performs its own checks using issuer-defined parameters stored at personalization:

Application Transaction Counter (ATC). The ATC increments with every transaction. Issuer-defined thresholds can trigger a requirement to go online after a certain number of offline transactions.
Offline spending limits. The card tracks cumulative offline amounts (Lower and Upper Consecutive Offline Limits) and can force online authorization when thresholds are exceeded.
Issuer-defined risk parameters. Additional risk rules encoded in the card’s Application Interchange Profile and Issuer Action Codes.

The combined result of terminal and card risk management produces one of three outcomes:

Approve offline — both parties are satisfied, and the card generates a Transaction Certificate (TC). The transaction completes without going online.
Decline offline — the card or terminal determines the transaction cannot be approved. The card generates an Application Authentication Cryptogram (AAC).
Go online — the most common outcome for attended POS in markets with reliable connectivity. The card generates an ARQC, and the transaction is sent to the issuer for real-time authorization.

The design principle here is layered risk assessment at the edge. The terminal and card don’t blindly forward every transaction to the issuer. They make independent decisions based on local context — and only escalate to the network when conditions require it. This is what makes the system resilient: it can still function, with bounded risk, when connectivity degrades.

Cryptogram Generation: The Cryptographic Heart of the Transaction

If the transaction goes online — and most attended POS transactions do — the card generates the Authorization Request Cryptogram (ARQC). This is the single most important security mechanism in the EMV flow.

The ARQC is an 8-byte MAC computed by the card using a session key derived from the card’s unique key and the current ATC. The inputs to the MAC include the transaction amount, currency, date, terminal country code, Terminal Verification Results (TVR), transaction type, and the Unpredictable Number (tag 9F37) — four random bytes generated by the terminal that add entropy to the cryptogram.

The result is a value that is unique to this specific transaction, on this specific card, at this specific terminal, at this specific moment. It cannot be predicted, replayed, or forged without the secret key embedded in the chip’s secure element.

The issuer independently derives the same session key using its master key hierarchy and recomputes the expected ARQC from the transaction data it receives. If the computed value matches the card’s ARQC, the cryptographic check passes — the card is genuine and the transaction data has not been altered in transit. If it doesn’t match, the transaction is declined.

This is why EMV dramatically reduced counterfeit fraud at the point of sale. With magnetic stripe, the card data was static — copy it once, replay it forever. With EMV, every transaction produces a unique cryptographic proof that cannot be manufactured without the key locked inside the chip. For a deeper treatment of the ARQC mechanism, key hierarchy, and implementation pitfalls, see the companion post on why EMV chip cards resist cloning.

The Network Journey: Terminal to Acquirer to Scheme to Issuer

Once the ARQC is generated and the terminal has completed its local processing, the transaction leaves the physical world and enters the financial messaging network.

The terminal constructs an ISO 8583 authorization request message — the standard message format used across the payment industry. The key data elements include the PAN (DE 2), processing code (DE 3), transaction amount (DE 4), the EMV chip data in TLV-encoded format (DE 55), the encrypted PIN block if applicable (DE 52), and the POS entry mode (DE 22) indicating how the card was read.

DE 55 deserves specific attention. It carries the chip data — ARQC, ATC, TVR, Application Interchange Profile, CDOL-related tags — that the issuer needs to validate the cryptogram. If the acquirer or any intermediary modifies, truncates, or incorrectly re-encodes DE 55, the issuer cannot reconstruct the ARQC input, and the cryptogram verification fails. This is a surprisingly common source of production failures.

The message flows through a well-defined chain:

The acquirer (or its processor) receives the message from the terminal, enriches it with merchant identification and routing data, and forwards it to the appropriate card network.

The card scheme (Visa, Mastercard, or others) acts as the switch — routing the message from the acquirer’s network to the correct issuer based on the BIN (Bank Identification Number) in the PAN. The scheme also applies its own fraud and compliance rules at this stage.

The issuer (or its processor) receives the message and performs the authorization decision.

This entire network journey — terminal to acquirer to scheme to issuer — typically completes in hundreds of milliseconds. The infrastructure that makes this possible is one of the most reliable real-time distributed systems ever built, processing billions of transactions per day across continents with sub-second latency requirements.

Issuer Decisioning: The Authorization Decision

The issuer is where the final authorization decision is made. It evaluates the transaction across multiple dimensions simultaneously.

Cryptographic validation. The issuer (or its HSM) derives the expected session key from the card’s master key and the ATC, recomputes the ARQC from the transaction data in DE 55, and compares it to the card’s submitted value. A match confirms the card is genuine and the data is intact. A mismatch means decline — no ambiguity.

Financial checks. Is there sufficient balance or credit limit? Has the account been flagged for any restrictions? Is the card active and in good standing?

Risk and fraud analysis. Modern issuer systems run real-time risk engines that evaluate velocity patterns (how many transactions in the last hour?), geolocation (is the card being used in a different country than the last transaction?), merchant category (is this a high-risk MCC?), and behavioral scoring — increasingly driven by machine learning models trained on the card portfolio’s transaction history. These checks run in milliseconds and produce a risk score that influences the authorization decision.

Regulatory and business rules. Strong Customer Authentication (SCA) requirements under PSD2 in European markets, MCC-based restrictions, and issuer-specific policies all factor into the decision.

The issuer responds with an authorization response code — approved, declined, or referral — and generates the Authorization Response Cryptogram (ARPC). The ARPC is the issuer’s cryptographic proof back to the card, computed using the ARQC and the authorization response code. When the terminal delivers the ARPC to the card, the card can verify that the response genuinely came from the issuer and was not fabricated or modified in transit.

The Return Path: Completing the EMV Flow

The issuer’s response travels back through the same chain in reverse: issuer to scheme, scheme to acquirer, acquirer to terminal. The response message carries the authorization response code, the ARPC, and optionally issuer scripts — commands that the terminal delivers to the card to update parameters, reset counters, or block the card if needed.

At the terminal, the EMV flow completes:

The terminal delivers the ARPC to the card. The card validates it, confirming the response is authentic. Based on the issuer’s decision and its own Terminal Action Codes, the terminal makes a final determination — and displays the result to the cardholder.

At this exact moment, the authorization is complete. The cardholder sees “Approved” and walks away. The merchant has an authorization code. But the money has not actually moved yet.

After Authorization: Clearing and Settlement

The “Approved” on the terminal screen is the end of authorization — not the end of the financial process.

Clearing happens later, typically in batches. The terminal (or the acquirer’s host) accumulates authorized transactions and submits them for clearing through the card scheme. The clearing message includes the final transaction details and reconciles what was authorized with what is being claimed.

Settlement is the actual movement of funds — from the issuer to the acquirer, less interchange fees and scheme fees. Settlement timelines vary by scheme, acquirer, and market, but T+1 or T+2 is typical for card-present transactions.

This distinction matters for merchants, acquirers, and anyone building reconciliation systems: an authorized transaction can still fail to settle. Reversals, chargebacks, and clearing mismatches are all post-authorization events that can alter the financial outcome. What the cardholder experienced as a completed payment may still be in flux for days.

The System as a Whole

What looks like a tap is actually a distributed system that spans continents and compresses cryptography, risk analysis, financial messaging, and real-time decisioning into a 2–3 second window. Every layer has a purpose:

EMV at the terminal authenticates the card, verifies the cardholder, and manages risk at the edge
The ARQC provides per-transaction cryptographic proof that binds the card, the terminal, and the transaction data into an unforgeable authorization request
The ISO 8583 message carries the transaction through a network of acquirers, schemes, and issuers with sub-second routing
The issuer validates the cryptogram, runs real-time fraud analysis, and makes the authorization decision
The ARPC closes the loop — the issuer proves its identity back to the card

The system works because each participant does its job within a well-defined protocol. The card proves itself to the terminal. The terminal proves the transaction to the acquirer. The acquirer routes it to the issuer. The issuer validates and responds. And the cryptographic thread — ARQC out, ARPC back — ensures that no participant can forge or tamper with the exchange without detection.

Billions of times per day, across millions of devices, networks, and issuers, this system is secure enough to prevent fraud, fast enough to feel instantaneous, and reliable enough that people never think about it.

Until something breaks. And when it does, every engineer in payments is reminded: those 2–3 seconds are anything but simple.

POS Architecture Beyond Certification: Financial Infrastructure, Fraud Detection, and the Expanding Attack Surface

contact@corebaseit.com (Vincent Bevia) — Sun, 29 Mar 2026 18:00:00 +0100

We talk about POS architecture in terms of certification, EMV flows, and cryptographic security. That’s the right starting point. But it’s not the full picture anymore. Two recent IEEE studies brought something into sharper focus for me: the role of the POS terminal is expanding faster than the security models built around it. In one direction, terminals are becoming primary banking interfaces for millions of previously unbanked people. In the other, the transaction data they generate is an underutilized fraud detection asset sitting in plain sight.

Both of these shifts have architectural consequences. And both demand that POS architects think beyond the certification checklist.

The Expanding Role of the POS Terminal

For decades, the POS terminal had a well-defined job: accept a card, build an authorization message, send it upstream, and return the result. The security model matched that scope — tamper-resistant hardware, secure key storage, encrypted PIN paths, EMV compliance. Design for the transaction. Certify the device. Deploy.

That model assumed the terminal was a single-purpose payment instrument operating inside a broader banking ecosystem. The cardholder had a bank. The bank had branches. The terminal was one touchpoint among many.

In mature markets, that assumption still mostly holds. But in emerging and underserved markets, it has quietly broken down. The POS terminal is no longer one touchpoint among many — in many cases, it is the only touchpoint. And that changes what POS architecture needs to account for.

When the Terminal Becomes the Bank

Research presented at the 2024 IEEE ICTAS conference analyzed POS terminal adoption in Nigeria’s banking sector through the lens of the Technology Acceptance Model (TAM). The findings are significant, not because TAM itself is new, but because of what the data reveals about how POS terminals are actually being used.

Millions of previously unbanked citizens now rely on POS terminals for deposits, withdrawals, bill payments, and fund transfers — bypassing the banking hall entirely. The study identified the key adoption drivers: availability where bank branches are not, operational flexibility, ease of use, and service efficiency. In practical terms, agents operating POS terminals in local shops and markets have become the de facto financial services layer for communities that formal banking infrastructure never reached.

This is not a convenience story. It is a financial inclusion story with direct security implications.

When a POS terminal processes a cash deposit for a customer who has no other banking access, the security requirements are fundamentally different from a contactless tap at a coffee shop. The terminal is holding value, managing balances, and serving as the trust anchor for the entire financial relationship. A compromised terminal in that context does not just expose card data — it can undermine the financial stability of individuals and communities that have no fallback.

The TAM analysis confirms what architects working in these markets already sense: perceived security directly influences adoption. Users who trust the terminal use it more. Users who don’t trust it return to cash — or worse, to informal financial channels with no protections at all. The terminal’s security posture is not just a compliance requirement. It is a condition of financial access.

For POS architects, this means the threat model has to expand. It is no longer sufficient to protect the payment transaction in isolation. When the terminal is the bank, you need to think about:

Data integrity beyond the transaction. If the terminal handles deposits, withdrawals, and balance inquiries, the data flowing through it has broader sensitivity than a standard card-present authorization.
Operator trust. In agent-banking models, the person operating the terminal is not a trained bank employee. The architecture needs to account for insider risk, social engineering, and operational error at the agent level.
Availability as a security property. If the terminal goes down and there is no branch to fall back on, the customer loses access to their money. Uptime, failover, and offline capability become security-adjacent concerns.
Audit and accountability. Every transaction at an agent terminal is a financial event with regulatory implications. The logging, reconciliation, and dispute resolution mechanisms need to be as robust as what a bank branch would provide — except they’re running on a device in a market stall.

None of this is theoretical. It is the operational reality in markets across Africa, Southeast Asia, and Latin America — and it is growing.

POS Logs as an Underutilized Fraud Detection Asset

The second study — presented at INISTA 2023 — took a completely different angle on POS data. Instead of looking at the terminal’s role in financial access, it looked at what the terminal’s own transaction logs can reveal about fraud when analyzed with machine learning.

The research applied classification algorithms — Random Forest, XGBoost, and LightGBM — directly to POS transaction logs from fast-food restaurant environments to detect cash register fraud. The dataset was heavily unbalanced, as fraud datasets always are: legitimate transactions vastly outnumber fraudulent ones. The researchers addressed this with resampling techniques, primarily ADASYN (Adaptive Synthetic Sampling), to generate synthetic minority samples and improve classifier performance on the fraud class.

The results were promising. The models demonstrated meaningful ability to distinguish fraudulent patterns from legitimate transactions using features extracted directly from POS logs — transaction timing, amount distributions, operator patterns, void and refund sequences.

This matters architecturally for a specific reason: the data already exists. POS terminals generate detailed transaction logs as a byproduct of normal operation. Every sale, every void, every refund, every discount, every drawer open event — it is all there. The question is not whether the data is available. The question is whether your system is capturing, retaining, and structuring it in a way that supports downstream analysis — or just archiving it for compliance and forgetting about it.

Most POS deployments fall into the second category. Logs are generated, batched, transmitted to a back office or cloud, and stored in a format optimized for reconciliation and regulatory retrieval. They are not structured for anomaly detection. They are not enriched with the contextual metadata — operator identity, shift timing, terminal location, transaction sequence context — that machine learning models need to identify suspicious patterns.

That is a design gap, not a technology gap. The ML techniques are mature. The infrastructure to run them is available. What is missing is the architectural decision to treat POS logs as a first-class fraud detection input rather than a compliance artifact.

What This Means for Fraud Architecture

The INISTA study focused on cash register fraud — employee-level theft through voids, refunds, and transaction manipulation. But the principle extends further. POS transaction data, properly captured and analyzed, can surface anomalies across multiple fraud vectors:

Operator-level fraud. Unusual void rates, refund patterns that don’t correlate with sales volume, transactions clustered at shift boundaries, repeated small-amount adjustments. These patterns are invisible in aggregate reporting but detectable with per-operator behavioral models.

Terminal-level anomalies. A terminal that suddenly shows a different transaction profile — different average amounts, different peak times, different card-present vs. card-not-present ratios — may indicate device tampering, software manipulation, or unauthorized use.

Network-level patterns. Across a fleet of terminals, coordinated anomalies can indicate organized fraud: multiple terminals showing the same unusual pattern simultaneously, or a pattern that moves from one terminal to another in sequence.

The architectural implication is that POS log infrastructure needs to be designed for analysis, not just storage. That means:

Structured logging with consistent schemas. Transaction events need standardized fields, timestamps with sufficient resolution, and operator/session context attached at the point of capture.
Real-time or near-real-time ingestion. Batch-only log processing means fraud is detected hours or days after it occurs. Streaming architectures — even lightweight ones — close that gap.
Feature engineering at the edge. Some anomaly signals are best computed close to the terminal: rolling averages, sequence analysis, deviation from baseline. Pushing all raw logs to a central system for every calculation adds latency and cost.
Feedback loops. A fraud detection system that identifies a suspicious pattern but has no mechanism to alert, flag, or restrict the terminal in real time is an analytics project, not a security control.

None of this requires exotic technology. It requires the architectural decision to invest in log infrastructure as part of the security model — not as an afterthought bolted on after deployment.

Security Cannot Be Retrofitted

Both studies point to the same underlying principle: the security architecture of a POS system must be designed for the terminal’s actual role, not just its original specification.

If the terminal is a payment device, secure the payment. If the terminal is a banking interface, secure the banking relationship. If the terminal generates data that can detect fraud, build the infrastructure to use it. In every case, the architecture has to carry the security model from day one — at the terminal level, at the data layer, and at the log infrastructure.

Retrofitting security into a deployed POS system is expensive, disruptive, and incomplete. Adding log analysis to a system that was never designed to capture structured logs means rewriting the logging layer, re-deploying firmware or software, and backfilling data that was never collected. Adding operator-level trust controls to an agent-banking terminal that was designed for a supervised retail environment means redesigning the interaction model. Adding real-time fraud detection to a batch-only architecture means rebuilding the data pipeline.

These are not small changes. They are the kind of changes that architects avoid by getting the design right in the first place.

The terminal is not just a payment device anymore. It is a trust interface — for the cardholder, for the merchant, for the financial system it connects to. The architecture should reflect that.

Design Principles for POS Architects

Expand the threat model beyond the transaction. If your terminals serve financial inclusion use cases, account for the broader data sensitivity, operator risk, and availability requirements that come with being someone’s only banking touchpoint.
Treat POS logs as a security asset. Design logging infrastructure for analysis, not just compliance. Structured schemas, real-time ingestion, and operator-level context are the minimum.
Build fraud detection into the architecture. The ML techniques work. The data exists. The gap is architectural: connecting the logs to the models and the models to operational response.
Design for the terminal’s actual role. Certification is necessary but not sufficient. The security model must match what the terminal actually does in the field — which may be far more than what the certification scope covers.
Security is a day-one decision. Retrofitting is always harder, more expensive, and less complete than building it in from the start. The earlier the security model is embedded in the architecture, the more robust and cost-effective it will be.

References

A. A. Adeolu, L. T. P. Salamntu and I. M. Paschal, “Point of Sales (POS) Terminals for Bank Service Delivery, the needs for Management of Information Security: A case of Nigeria’s Banking Sectors,” 2024 Conference on Information Communications Technology and Society (ICTAS), Durban, South Africa, 2024, pp. 150–160. DOI: 10.1109/ICTAS59620.2024.10507146
E. Begen, İ. U. Sayan, A. Tuğrul Bayrak and O. T. Yıldız, “Point of Sale Fraud Detection Methods via Machine Learning,” 2023 International Conference on Innovations in Intelligent Systems and Applications (INISTA), Hammamet, Tunisia, 2023, pp. 1–5. DOI: 10.1109/INISTA59065.2023.10310515
EMVCo — EMV Specifications for Payment Systems, Books 1–4
PCI SSC — PCI PTS Device Security Requirements
Point-of-Sale Systems Architecture — Volume 1: A Practical Guide to Secure, Certifiable POS Systems — broader context for terminal security, certification, and architecture design

Reasoning Models and Deep Reasoning in LLMs: Chain-of-Thought, Tree of Thoughts, and Test-Time Compute

contact@corebaseit.com (Vincent Bevia) — Thu, 26 Mar 2026 20:00:00 +0100

After reading Wei et al.’s work on Chain-of-Thought, the Tree of Thoughts paper from Princeton, and several recent studies on test-time compute scaling, I wanted to organize what I learned about how reasoning actually works — and doesn’t work, as of today — in large language models.

Language models don’t reason. Not in the way humans do. They predict the next token based on patterns learned from training data. But something interesting happens when you force them to show their work: the outputs get dramatically better. Not because the model suddenly “thinks” — but because the structure of the prompt shapes the computation in ways that produce more accurate results.

This post covers the three major strategies for eliciting reasoning behavior from LLMs: Chain-of-Thought prompting, Tree of Thoughts, and Test-Time Compute Scaling. These are not incremental prompt tricks. They represent a shift in how we architect interactions with language models — from single-shot question-answer to structured, multi-step inference pipelines.

Chain-of-Thought Prompting: Forcing the Model to Show Its Work

Chain-of-Thought (CoT) prompting was introduced by Wei et al. at Google Research in 2022. The idea is deceptively simple: instead of asking the model for a final answer directly, you provide examples that include intermediate reasoning steps — and the model learns to generate its own.

How It Works

Standard prompting:

Q: If a store has 23 apples and sells 17, how many remain?
A: 6

Chain-of-Thought prompting:

Q: If a store has 23 apples and sells 17, how many remain?
A: The store starts with 23 apples. It sells 17. 23 - 17 = 6. The store has 6 apples remaining.

The difference looks trivial. The performance difference is not.

Why It Works

When the model generates intermediate steps, it effectively decomposes a complex problem into simpler sub-problems that it can solve sequentially. Each intermediate token generated becomes part of the context for the next prediction. The model doesn’t “plan” — it creates a chain of computations where each step constrains and informs the next.

Wei et al. demonstrated that CoT prompting with PaLM (540B parameters) achieved state-of-the-art accuracy on the GSM8K math benchmark, surpassing even fine-tuned GPT-3 with a verifier. The gains were significant across arithmetic reasoning, commonsense reasoning, and symbolic reasoning tasks.

The Critical Caveat: Scale Dependency

CoT prompting only works reliably in large models. In smaller models (below roughly 100B parameters), chain-of-thought prompting often produces plausible-looking but incorrect reasoning chains. The model generates steps that look logical but contain errors — and because the steps look coherent, these errors are harder to detect than a simple wrong answer.

This is an important architectural consideration: if you’re building a system that relies on CoT reasoning, model size is not optional. Using CoT with an undersized model doesn’t just degrade gracefully — it can actively mislead.

Self-Consistency: Majority Voting Over Reasoning Paths

A natural extension of CoT, introduced by Wang et al. at Google Brain (ICLR 2023), is Self-Consistency. The insight: for any complex problem, there are usually multiple valid reasoning paths that arrive at the same correct answer.

How It Works

Sample multiple reasoning paths. Instead of generating a single chain-of-thought with greedy decoding, sample 5, 10, or 40 diverse reasoning chains using temperature sampling
Extract the final answer from each chain. Ignore the intermediate reasoning — just collect the answers
Majority vote. The most common answer across all sampled chains is selected as the final output

Why It Matters

Self-Consistency treats the reasoning chain as a stochastic process rather than a deterministic one. Any single chain might contain errors. But if you sample enough chains, the correct answer tends to appear more frequently than any specific incorrect answer — because there are many ways to reason correctly, but errors tend to be more random and distributed.

The empirical results are substantial: +17.9% on GSM8K, +11.0% on SVAMP, +12.2% on AQuA. These are large gains from a technique that requires no additional training — only more inference-time computation.

The trade-off is direct: you’re spending N times the compute for significantly higher accuracy. Whether that trade-off is worth it depends on the cost of being wrong.

Tree of Thoughts: Deliberate Search Over Reasoning Space

Chain-of-Thought is linear. You generate one chain, step by step, left to right. If a reasoning step goes wrong early, everything downstream is compromised. There’s no backtracking, no exploration of alternatives.

Tree of Thoughts (ToT), introduced by Yao et al. at Princeton (NeurIPS 2023), addresses this by turning reasoning into a search problem.

How It Works

Instead of generating a single linear chain, ToT:

Decomposes the problem into intermediate “thoughts” — coherent reasoning units (a sentence, a paragraph, a partial solution)
Generates multiple candidate thoughts at each step — branching the reasoning tree
Evaluates each candidate — using the model itself to assess which thoughts are most promising
Searches the tree — using breadth-first search (BFS) or depth-first search (DFS) to explore the most promising paths
Backtracks when needed — abandoning dead-end reasoning paths and exploring alternatives

The Results Are Striking

On the Game of 24 (a mathematical reasoning task), GPT-4 with standard CoT prompting achieved 4% success. With Tree of Thoughts: 74%. That’s not a marginal improvement — it’s a qualitative shift in capability.

The Engineering Reality

ToT is powerful but expensive. Each “thought” evaluation requires a model call. A tree with branching factor 3 and depth 5 requires dozens to hundreds of inference calls per problem. For latency-sensitive applications, this is prohibitive. For high-stakes decisions where accuracy matters more than speed — architecture reviews, certification analysis, complex debugging — the trade-off may be worth it.

There’s also a deeper point: ToT demonstrates that the reasoning bottleneck is often in the inference strategy, not the model itself. The same model (GPT-4) goes from 4% to 74% accuracy by changing how it explores the problem space. The weights are identical. The architecture of the interaction is what changed.

Test-Time Compute Scaling: Spending More Compute Where It Matters

The most recent evolution in reasoning strategies is Test-Time Compute Scaling (TTS) — the principle behind OpenAI’s o1 and o3 models, and an increasingly active area of open-source research.

The idea: instead of fixing the computation budget at inference time, allocate more compute to harder problems. Let the model “think longer” when the problem demands it.

How It Works

TTS models are trained to produce extended reasoning traces before committing to a final answer. The model generates an internal chain-of-thought — sometimes hundreds or thousands of tokens — working through the problem step by step before producing its output.

Two key mechanisms:

Sequential scaling: The model generates longer reasoning chains for harder problems. More tokens = more intermediate computation = (in theory) better answers. This is what o1 does internally.

Parallel scaling: Sample multiple independent reasoning attempts and select the best one — either through majority voting (like Self-Consistency) or through a learned verifier that scores each attempt.

What the Research Shows

Recent large-scale studies reveal important nuances that temper the initial enthusiasm:

No single strategy universally dominates. A study spanning 30+ billion tokens across eight open-source models (7B–235B parameters) found that optimal TTS strategies depend on problem difficulty, model size, and trace length. There is no one-size-fits-all approach.

Longer chains don’t always help. Research on o1-like models (QwQ, DeepSeek-R1, LIMO) found that correct solutions are often shorter than incorrect ones. The models’ self-revision capabilities in longer chains frequently degrade performance — the model talks itself out of a correct answer. This is a direct challenge to the assumption that “more thinking = better answers.”

Parallel beats sequential in many cases. Sampling multiple independent solutions achieves better coverage and scalability than letting a single chain run longer. This has practical implications: it’s often more effective to generate 10 short reasoning attempts and vote than to generate one very long chain.

Simple methods can be surprisingly effective. The s1 model demonstrated that fine-tuning on just 1,000 curated reasoning examples, combined with budget forcing (controlling how long the model thinks via prompting), exceeded o1-preview on competition math by up to 27%. Massive training budgets are not always necessary.

The Hierarchy of Reasoning Strategies

These techniques form a natural progression in complexity and capability:

Strategy	Mechanism	Compute Cost	Best For
Standard prompting	Direct question → answer	1x	Simple factual queries
Chain-of-Thought	Linear step-by-step reasoning	1x (longer output)	Arithmetic, multi-step logic
Self-Consistency	Multiple CoT chains + majority vote	Nx (N samples)	High-stakes decisions where accuracy matters
Tree of Thoughts	Branching search with evaluation and backtracking	10–100x	Complex planning, search problems
Test-Time Compute Scaling	Dynamic compute allocation per problem	Variable	Hard reasoning, competition-level problems

Each level trades compute for accuracy. The engineering question is always: what’s the cost of being wrong?

What This Means for Engineers

These Are Architectural Decisions, Not Prompt Tricks

Choosing between CoT, Self-Consistency, ToT, and TTS is an infrastructure decision. It affects latency, cost, reliability, and the failure modes of your system. Treat it like choosing a database or a caching strategy — not like choosing a font.

Reasoning Quality Is Bounded by Verification

All of these strategies produce more confident-looking output. That makes verification more important, not less. A model that generates a 500-token reasoning chain with a wrong conclusion is harder to catch than one that outputs a single wrong answer. The reasoning chain creates an illusion of rigor.

If you’re in a regulated domain — payments, medical, legal — you need to architect verification into the pipeline, not just trust that more reasoning steps equals more accuracy.

The Model Is Not Reasoning — It’s Computing

This is worth repeating. These techniques improve output quality by structuring computation, not by enabling understanding. The model doesn’t “know” whether its intermediate steps are correct. It doesn’t have beliefs or intentions. It’s generating tokens that are statistically likely given the preceding context.

This isn’t a philosophical quibble. It has practical engineering consequences: the model can generate a perfectly structured, internally consistent reasoning chain that reaches a confidently stated wrong answer. The chain looks logical. The conclusion is wrong. And the better the reasoning strategy, the more convincing the wrong answers become.

Build for verification. Not for trust.

References

Wei, J. et al. “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models.” NeurIPS 2022. arxiv.org/abs/2201.11903
Wang, X. et al. “Self-Consistency Improves Chain of Thought Reasoning in Language Models.” ICLR 2023. openreview.net
Yao, S. et al. “Tree of Thoughts: Deliberate Problem Solving with Large Language Models.” NeurIPS 2023. arxiv.org/abs/2305.10601
“The Art of Scaling Test-Time Compute for Large Language Models.” 2025. arxiv.org/abs/2512.02008
Muennighoff, N. et al. “s1: Simple Test-Time Scaling.” 2025. arxiv.org/abs/2501.19393
“Revisiting the Test-Time Scaling of o1-like Models.” ACL 2025. aclanthology.org
The Obsolescence Paradox: Why the Best Engineers Will Thrive in the AI Era — engineering judgment in the age of AI reasoning systems
Prompt Engineering for POS — practical CoT applications in payment systems
AI Sycophancy — why confident-looking AI output still requires verification

Why PIN Still Matters in Card-Present Payments

contact@corebaseit.com (Vincent Bevia) — Mon, 23 Mar 2026 10:00:00 +0100

For years, PIN has been treated as a legacy payment ritual: an extra step at the terminal, a bit of friction in a world shaped by contactless cards, mobile wallets, and invisible checkout. That interpretation misses what PIN actually does.

In card-present payments, EMV does an excellent job of authenticating the card — transaction-specific cryptographic evidence (the ARQC) makes cloning and counterfeit fraud much harder. But EMV does not, by itself, prove that the person holding the card is the legitimate cardholder. That is a separate problem. It is exactly why PIN still matters.

The Threat Model: What Chip Solves vs. What PIN Solves

Treating “chip security” as if it solved everything leads to bad risk decisions.

EMV chip addresses the authenticity of the card and the integrity of transaction data. The key question it answers is: Is this card genuine?

PIN addresses a different question: Is the person presenting this card the legitimate cardholder?

A genuine card in the wrong hands is still a fraud risk. A stolen card can still be inserted into a terminal. Post-EMV data bears this out: markets that used chip-and-signature or chip-and-no-CVM saw counterfeit fraud fall sharply but retained relatively high lost-and-stolen fraud; chip-and-PIN markets tended to show stronger reductions across both. The chip and PIN do not compete — they are two controls for two distinct problems in the same flow.

Cardholder Verification in EMV: Where PIN Fits

Within EMV, PIN is a Cardholder Verification Method (CVM). The baseline methods include:

Online PIN — encrypted at the terminal, verified by the issuer or its HSM during authorisation.
Offline PIN — verified on the chip, with retry limits enforced by a PIN Try Counter.
Signature — human comparison; no cryptographic binding to the cardholder.
No CVM — low-value and some unattended or contactless contexts.

Issuers encode strategy in the CVM List (tag 8E); the kernel walks the list and applies the first mutually supported method whose condition is true. Architecturally, preferring PIN over signature or no-CVM is the decision to demand real cardholder authentication rather than convenience-only verification.

How Online PIN Protects the PIN

In online PIN, sensitive handling stays in tamper-resistant hardware and issuer-side HSMs:

Cardholder enters the PIN on a PCI-approved PIN Entry Device (PED).
The PED formats an ISO PIN block (typically Format 0) and encrypts it before it leaves the secure device.
The acquirer forwards the encrypted PIN block to the issuer; an HSM decrypts and verifies against a protected reference.
The issuer enforces retry limits and returns an authorisation decision; the terminal records the outcome in the Terminal Verification Results (TVR).

Merchant systems and networks see only an encrypted PIN block — never the clear PIN. Even if the merchant environment is compromised, an attacker may get card data and cryptogram material, but not cardholder PINs. For POS and acquiring architects, the job is a clean end-to-end PIN security domain around PEDs and HSM paths — not handling PINs in application logic.

Offline PIN: On-Chip Verification and Real-World Resilience

Offline PIN moves cardholder verification onto the chip — essential when connectivity is intermittent or absent (fuel, transit, rural merchants, resilience-oriented acceptance).

Mechanics in brief: the card holds a reference PIN and a PIN Try Counter (tag 9F17) in secure memory; the PED captures entry and the chip verifies via EMV VERIFY; on failure the counter decrements; CVM rules determine whether another method can apply or verification fails entirely. The issuer does not see the PIN, but can trust the chip’s outcome; brute force is capped by the try counter. Exhaust the counter and the card is PIN-locked until issuer reset or replacement.

That same property makes PIN a continuity control, not only a fraud control: verification can still run when the terminal cannot reach the issuer immediately. A mechanism that only works when every upstream dependency is healthy is useful; one that still functions when conditions degrade is strategically valuable. Offline PIN costs more to implement and test than online PIN — but it preserves strong CVM semantics at the edge.

What PIN Mitigates in Acquiring

Lost and stolen cards — Without PIN, a thief can insert or tap a genuine card up to scheme limits until risk rules intervene. With PIN, they need the secret; guessing is bounded by issuer controls or the offline try counter. The attacker needs both the instrument and the knowledge factor.

Data-only compromises — Skimming and malware can capture PAN, expiry, and track-equivalent data; in EMV+PIN environments that is often insufficient for PIN-verified card-present abuse, pushing criminals toward CNP, PIN-less debit, and social engineering — each addressable with different controls.

Disputes and liability — A transaction logged as PIN-verified is treated as higher-assurance evidence of cardholder involvement. Networks still differentiate these categories in pricing and risk models; empirically, PIN-verified flows tend to show lower fraud per transaction than signature or no-CVM where those comparisons apply.

Contactless, Limits, and CDCVM

Contactless did not retire PIN — it rebalanced when it appears. Low-value tap often uses no CVM by design: bounded exposure for speed. Above the contactless CVM limit (and with cumulative counters where schemes require), terminals step up — for card-based flows, typically online PIN. The framing is not contactless replaced PIN; it is contactless reduced visible PIN in low-risk paths, while PIN remains the default strong CVM when risk rises.

On phones, consumers may use biometrics or device passcode instead of keypad PIN — Consumer Device CVM (CDCVM) satisfies the same architectural requirement: strong cardholder verification with a different interface. Visible PIN declined; the requirement for a strong CVM did not.

Known Weaknesses — In Context

Relay attacks and historical PIN-bypass flaws are real and deserve acknowledgment: they are implementation and ecosystem issues, tightened by certification, ARQC binding, and monitoring — not proofs that PIN is useless. For the bulk of attacks, requiring a correct PIN still blocks trivial misuse of stolen cards. PIN is one layer in a stack, not the only layer.

Design Implications for Acquirers and POS Architects

Prefer PIN-capable CVM strategies where rules allow, over signature-only or no-CVM for attended POS when you need cardholder assurance.
Set sensible contactless CVM limits and counters; step up to PIN or CDCVM above thresholds to bound lost-and-stolen exposure.
Isolate the PIN path: certified PEDs, HSM-backed verification, no clear PIN in merchant logic or logs.
Invest in offline PIN where outages or offline-first models matter — complexity is justified by edge resilience.
Use CVM outcomes in risk analytics — a PIN-verified ARQC with a clean TVR is a different signal from no-CVM contactless at a new merchant.

The broader stack is layered: EMV cryptography for the card, secure PIN capture and HSM verification for the cardholder, device trust, risk engines, tokenisation where relevant, and scheme compliance. The principle is not PIN or modern security — it is PIN as part of layered modern security.

The Bottom Line

Payments security is not only about verifying the card. It is about verifying the cardholder, assigning liability fairly, and keeping acceptance secure when networks are imperfect. PIN stays relevant because it still does that job at scale: simple, widely deployed, strong evidentiary value, and usable offline alongside chip authentication.

The future is not “PIN everywhere forever” or “PIN disappears” — it is layered authentication: chip for the card, PIN or equivalent strong CVM for the user, risk engines for context, secure devices at the edge. EMV made card data harder to abuse; PIN and its successors make the card harder to abuse in the wrong hands. You still need both.

The ideas here align with how CVM, terminals, and acquiring risk fit together in Point-of-Sale Systems Architecture — Volume 1: A Practical Guide to Secure, Certifiable POS Systems — security as a system, not a single feature.

References

EMVCo Book 3 (Application Specification) — CVM List, VERIFY, cardholder verification
EMVCo Book 4 — PED and PIN entry interfaces
ISO 9564 — PIN encipherment and PIN block formats
PCI PTS — POI and PIN security requirements
PIN Translation: Bridging Cryptographic Worlds Inside the HSM — PIN block handling in the authorisation path

Why EMV Chip Cards Resist Cloning: The ARQC Mechanism Explained

contact@corebaseit.com (Vincent Bevia) — Sat, 21 Mar 2026 20:00:00 +0100

Every chip card generates a unique cryptographic proof each time you tap or insert it. That proof is why cloning a chip card’s transaction capability is effectively impossible — and why the payment industry invested billions migrating from magnetic stripe.

A precise distinction is worth making upfront: a criminal can still copy visible card data — PAN, expiry, track-equivalent data. What they cannot realistically clone is the chip’s cryptographic capability for generating valid dynamic transaction cryptograms. The secret key embedded in the secure element never leaves the chip, and without it, no amount of copied data lets an attacker produce the next valid ARQC. The security point is not “nothing from the card can ever be copied.” It is “the chip’s transaction authentication cannot be duplicated without the embedded key.” That is the mechanism that makes chip cards fundamentally resistant to cloning in a way that magnetic stripe never was.

This post explains what the ARQC does, why it works, and where practitioners still get the implementation details wrong. For the full technical deep-dive — key hierarchy, session key derivation, ARPC response, and the complete authorization flow — see the companion post on EMV cryptograms.

The ARQC: A Per-Transaction Cryptographic Proof

The Authorization Request Cryptogram (ARQC) is an 8-byte MAC generated by the chip card for every online transaction. The card combines the transaction amount, currency, date, terminal data, and a random number with a secret key stored in the chip’s secure element — producing a value unique to that exact transaction.

The issuer independently recomputes the expected value using the master key hierarchy. A match means the cryptographic check succeeded for the supplied transaction data. A mismatch means the cryptographic check failed and the transaction should not be approved on that basis.

This is not a signature. It’s not a hash. It’s a symmetric MAC computed with a session key that only the card and the issuer can derive. The inputs are transaction-specific, the key is card-specific, and the counter ensures no two transactions ever produce the same result.

$$ \text{ARQC} = \text{MAC}_{\text{SK}}(\text{CDOL1 Data}) $$

Where the session key (\text{SK}) is derived from the card’s unique key and the Application Transaction Counter (ATC), and the CDOL1 data includes the transaction amount, currency, date, terminal country code, and the Unpredictable Number — everything needed to bind this cryptogram to this specific transaction on this specific card at this specific moment.

Every Major Attack Vector Is Neutralised

The ARQC mechanism doesn’t prevent one type of fraud. It prevents the entire class of attacks that magnetic stripe was vulnerable to.

Replay. The Application Transaction Counter increments with every transaction. Issuers track ATC progression and use it, together with the rest of the transaction context, to detect stale or suspicious repeats. Capture a valid authorization and replay it later, and the transaction should fail because the cryptographic context no longer lines up as a fresh, valid transaction. In EMV, one-time use is enforced through dynamic cryptography and issuer-side validation, not by convention.

Cloning. This is where the distinction matters most. A criminal can copy visible card data — PAN, expiry, track-equivalent data, service code. Some of that data is exposed during normal transaction processing. What they cannot clone is the cryptographic key inside the secure element, and without that key, they cannot generate the next valid ARQC. They have the card’s identity but not its ability to prove that identity. That is the fundamental difference from magnetic stripe: the stripe is a passive data store — copy it and you have a perfect functional clone. The chip is an active computing device that performs cryptographic operations internally and never exposes its secrets. Copying the data without the key gives you a card that looks right but can’t authenticate.

Tampering. Change the amount from ten euros to a thousand and the cryptogram no longer matches. The amount is an input to the MAC computation. Modify any input and the output changes unpredictably. The issuer recomputes the expected ARQC from the transaction data it receives — if the data was altered in transit, the recomputed value won’t match the card’s original cryptogram.

Compare all of this to magnetic stripe: a static CVV, the same value every swipe, no counter, no dynamic proof. Copy it once, replay it forever. That’s not a theoretical weakness — it was the practical reality of card fraud for decades, and it’s the reason the industry moved to chip.

Where Practitioners Still Get It Wrong

The ARQC mechanism is well-designed. The implementation, however, is where mistakes happen — and they happen across all three sides of the transaction.

Terminal Developers

Don’t forget the Unpredictable Number. Tag 9F37 provides four random bytes that add critical entropy to the cryptogram input. If your terminal generates weak random numbers — or worse, reuses them — you reduce the cryptographic strength of the ARQC. The Unpredictable Number is one of the key inputs that helps prevent prediction and pre-play style abuse when combined with the rest of the transaction data and issuer-side controls. Make sure your random number generation is actually random.

Also: transmit all EMV tags required by the issuer in DE 55. Missing tags mean the issuer can’t reconstruct the ARQC input, which means the cryptogram can’t be verified, which means the transaction gets declined — not because of fraud, but because of incomplete data.

Issuer Processors

ATC gap thresholds matter more than most teams realise. The issuer tracks the last-seen ATC per card and expects each new transaction to have a higher value. But cards also increment the ATC for offline transactions and declined attempts. A cardholder who uses their card at several offline terminals before going online will present an ATC that’s jumped ahead.

Set the gap threshold too strict and you cause false declines on legitimate cardholders — a direct revenue and customer experience problem. Set it too loose and you widen the window for replay attacks. There’s no universal right answer; the threshold is a risk management decision that should be informed by your card portfolio’s behaviour patterns.

Acquirers

Preserve DE 55 integrity end to end. The EMV data in Data Element 55 of the ISO 8583 message is TLV-encoded chip data that must reach the issuer in the expected form for cryptogram verification to succeed. If your gateway modifies, truncates, or incorrectly re-encodes DE 55, you break the verification chain. The issuer will recompute the ARQC from the data it receives — if that data no longer matches what the card originally computed over, the verification fails and the transaction is declined. This sounds obvious, but it’s a surprisingly common source of cryptogram verification failures in production.

Why This Matters

The ARQC is the cryptographic heart of EMV. It is the reason chip card fraud at the point of sale dropped dramatically after migration — Visa reported a 76% reduction in counterfeit fraud at chip-enabled merchants in the US within the first few years of the liability shift. Mastercard reported similar numbers. The mechanism works.

It’s also the reason liability shifted to merchants who don’t support chip transactions. The technology exists to prevent fraud. Not using it is a choice, and the schemes made that choice expensive.

The security claim was never “nothing on the card can be copied.” Card data has always been partially visible — the PAN is printed on the face, the track data is readable from the chip’s public files. The claim is more precise and more powerful: the chip’s ability to generate valid transaction authentication cannot be duplicated without the embedded key. That is what makes cloning a chip card fundamentally different from cloning a magnetic stripe — you can copy the data, but you can’t copy the capability. And in EMV, the capability is what the issuer actually verifies.

For engineers building terminal software, issuer processing systems, or acquirer gateways, the ARQC is not an abstract concept — it’s a concrete mechanism that touches your code, your message formats, and your operational procedures. Getting it right means understanding not just that it works, but how it works and where the implementation details matter.

Scheme-Level Signaling: How Networks Identify Unattended Transactions

contact@corebaseit.com (Vincent Bevia) — Mon, 16 Mar 2026 00:00:00 +0100

PCI PTS classifies devices at the hardware level. But Visa and Mastercard classify transactions at the message level. No scheme inspects the physical terminal to determine whether it is attended or unattended — that determination is inferred entirely from data elements in the authorisation message. If the message says “attended,” the transaction is treated as attended regardless of the hardware’s PCI PTS listing. If the message says “unattended,” the scheme applies unattended rules — CVM selection, floor limits, interchange category, and compliance edits — accordingly.

This distinction matters because it means the terminal application and host gateway are jointly responsible for setting the correct environment indicators on every transaction. Getting the hardware certified as UPT is necessary but not sufficient; the authorisation messages must consistently declare the unattended context, or the certification is operationally meaningless.

The Three Signaling Points in ISO 8583

Three data elements in a standard ISO 8583 authorisation message convey the attended/unattended classification to the scheme:

Data Element	Role	Attended Value (Typical)	Unattended Value (Typical)
DE 25 — POS Condition Code	Declares the terminal environment directly.	`00` — Normal presentment	`02` — Unattended terminal, customer operated (CAT)
DE 22 — POS Entry Mode	Describes how the PAN was captured (chip, contactless, magstripe, manual) and PIN capability.	Standard chip/contactless values	Same values — DE 22 does not distinguish attended from unattended
Terminal Type / POS Environment (scheme-specific subfields)	Visa TADG and Mastercard specifications define subfields for terminal type, CAT level, and environment classification.	POS terminal — cardholder present, attendant present	CAT terminal — cardholder present, no attendant

The scheme combines these fields to classify the transaction. A correctly coded unattended transaction carries a consistent signal across all three: terminal type set to CAT, POS condition code set to 02 (unattended/customer-operated), and the environment subfield declaring cardholder-present with no attendant. Networks then apply business rules over these fields — interchange routing, risk scoring, CVM validation, and compliance checks — to enforce unattended-specific policies.

Who Sets These Indicators

The terminal application sets the values based on its configured environment. A vending machine, parking terminal, or AFD must be configured to emit unattended indicators on every transaction — this is not dynamic or per-transaction logic in most deployments, it is a fixed configuration reflecting the physical reality of the deployment.

The acquirer or gateway is responsible for passing these indicators through to the scheme correctly and can face compliance edits, interchange penalties, or scheme fines if the coding is wrong. An attended terminal miscoded as unattended — or vice versa — creates downstream problems: incorrect CVM handling, mispriced interchange, distorted issuer risk scoring, and potential L3 certification failures.

One Device, Two Configurations — Never Both at Once

A single physical SmartPOS device can support both attended and unattended use cases across different deployments. The same hardware model might run an attended retail application in one merchant’s checkout lane and an unattended kiosk application in another merchant’s lobby. However, for any given transaction, the device must behave as one or the other — the classification is binary at the message level, and schemes expect it to be consistent with how the cardholder actually interacts with the terminal.

This means the two deployments are effectively two different configurations and two different certification stories, even on identical hardware:

Different EMV kernel parameters: Terminal Type (Tag 9F35) values 21/22 for attended vs. 23/24 for unattended, different CVM lists, different TAC values.
Different ISO 8583 field values: DE 25, terminal type subfields, and environment indicators.
Different L3 certification cycles: unattended certification is not an extension of attended certification — it requires a separate test plan.
Different PCI PTS scope: the unattended deployment may require UPT classification, SRED, and C2.4 prompt control that the attended deployment does not.

Configuration Consistency Is a Compliance Requirement

Using an attended configuration in a truly unattended scenario — or an unattended configuration on an attended device — is not a grey area. It produces wrong CVM sets, wrong floor limits, and miscoded POS condition codes. These inconsistencies will surface during L3 testing, scheme compliance monitoring, or acquirer audits. The environment classification must reflect the physical reality of how the cardholder interacts with the terminal, and it must be consistent across hardware certification, EMV kernel parameters, and ISO 8583 message coding.

The “semi-attended” concept — self-checkout lanes with a supervisor nearby, pay-at-table devices in restaurants — is a commercial and acquirer-level classification, not a PCI or scheme-level one. PCI PTS recognises only attended and unattended. Some acquirers and processors layer “semi-attended” as an operational distinction for risk management purposes, but the authorisation message still carries a binary attended-or-unattended signal. When defining certification scope for a semi-attended deployment, clarify with the acquirer whether the environment maps to attended or unattended for scheme messaging and compliance purposes.

References

Visa — Technical Agent Data Guide (TADG) and related terminal environment guidance.
Mastercard — Transaction Processing Rules and scheme-specific terminal / environment requirements.

Transformers vs. Diffusion Models: Not All AI Is the Same

contact@corebaseit.com (Vincent Bevia) — Sat, 14 Mar 2026 14:00:00 +0100

We casually say “AI can write, AI can draw, AI can code” as if it’s one thing. It’s not. Two of the most talked-about model families in AI today solve fundamentally different problems using fundamentally different mechanisms — and conflating them leads to bad engineering decisions, bad product expectations, and bad policy.

This post breaks down the two architectures that dominate the current AI landscape: Transformers and Diffusion Models. What they do, how they work, and why the distinction matters.

Transformers: Sequence Understanding Machines

The Transformer architecture was introduced in the 2017 paper “Attention Is All You Need” by Vaswani et al. at Google. It replaced recurrent neural networks (RNNs) as the dominant architecture for sequence modeling, and it’s now the foundation of virtually every major language model — GPT, Claude, Gemini, LLaMA, Mistral, and others.

What They Do

Transformers model relationships within sequences. Given a sequence of tokens (words, subwords, code tokens, or any structured data), the Transformer learns which tokens are relevant to which other tokens — regardless of their distance in the sequence. This is the core innovation: self-attention.

They excel at:

Language understanding — parsing meaning, context, and nuance from text
Text generation — producing coherent, contextually appropriate language
Code generation and reasoning — understanding syntax, logic, and structure
Sequence-to-sequence tasks — translation, summarization, question answering

How They Work

At a high level:

Input tokenization: Text is split into tokens and converted to numerical embeddings
Positional encoding: Since Transformers process all tokens in parallel (not sequentially like RNNs), position information is added explicitly
Self-attention layers: Each token attends to every other token in the sequence, computing relevance scores. This is what allows the model to capture long-range dependencies — a word at the beginning of a paragraph can directly influence the interpretation of a word at the end
Feed-forward layers: After attention, each token passes through a feed-forward network for further transformation
Stacking: Multiple layers of attention + feed-forward are stacked (modern models use dozens to over a hundred layers), building increasingly abstract representations
Output generation: For generative models, the output is a probability distribution over possible next tokens, sampled autoregressively — one token at a time

The Key Insight: Attention

The self-attention mechanism computes, for every token in the input, a weighted sum of all other tokens based on learned relevance. This allows the model to focus on the right context dynamically. When you ask a language model about “the bank” in a sentence about rivers, attention helps it distinguish that from “the bank” in a financial context — by looking at surrounding tokens.

This is computationally expensive (quadratic in sequence length), which is why context window sizes, efficient attention variants, and inference optimization are active areas of research.

Diffusion Models: Generation from Noise

Diffusion models took a different path. Instead of modeling sequences, they model the distribution of data — typically images — and generate new samples by reversing a noise process.

The key papers include “Denoising Diffusion Probabilistic Models” (Ho et al., 2020) and the latent diffusion work behind Stable Diffusion (Rombach et al., 2022). These models power most of today’s image generation tools: DALL-E, Midjourney, Stable Diffusion, and increasingly video and audio generation.

What They Do

Diffusion models generate high-quality, coherent data from random noise. They’re primarily used for:

Image generation — photorealistic images, art, design assets
Image editing — inpainting, outpainting, style transfer
Video generation — emerging applications producing short video clips
Audio synthesis — music and speech generation

How They Work

The process has two phases:

Forward process (training):

Take a real image from the training set
Gradually add Gaussian noise over many timesteps until the image becomes pure random noise
The model learns to predict and reverse each step of this corruption

Reverse process (generation):

Start with pure random noise
The model iteratively removes noise, step by step
Each step refines the image, adding structure and detail
After enough steps, a coherent, realistic image emerges

The model doesn’t “understand” images in the way a human does. It has learned the statistical structure of image data — what pixel patterns, textures, shapes, and compositions are likely — and uses that knowledge to guide the denoising process.

What makes this powerful is how the prompt steers the process. At each denoising step, the model predicts a slightly cleaner version of the image, using the text prompt as a guide for what should emerge from the noise. Over many steps — typically 50 to 1000 — the noise fades and coherent structure appears: edges sharpen, textures form, composition resolves. The prompt doesn’t create the image directly; it shapes the direction the denoising takes at every step.

This capability is already transforming fields beyond engineering — design, marketing, media, accessibility. It allows AI systems to take an idea expressed in one form (language) and bring it to life in another (visual). That cross-modal translation is what makes diffusion models architecturally significant, not just technically impressive.

Unlike a Transformer that produces output in a single forward pass (or token-by-token), diffusion models produce output through many refinement steps. This iterative process is what gives them their characteristic quality — but also makes them slower than single-pass models.

Modern variants (latent diffusion) work in a compressed latent space rather than directly on pixels, dramatically reducing computational cost while maintaining quality.

Side-by-Side Comparison

Aspect	Transformers	Diffusion Models
Primary domain	Language, code, structured sequences	Images, video, audio
Core mechanism	Self-attention over token sequences	Iterative denoising of noise
Output method	Autoregressive (token by token)	Iterative refinement (many steps)
Training data	Text corpora, code repositories	Image datasets, visual data
Strengths	Context understanding, reasoning, generation of structured output	High-quality visual generation, creative content
Limitations	Quadratic attention cost, hallucination, sycophancy	Slow generation, less control over fine details, prompt sensitivity
Key papers	Attention Is All You Need (Vaswani et al., 2017)	Denoising Diffusion Probabilistic Models (Ho et al., 2020)
Example systems	GPT-4, Claude, Gemini, LLaMA	DALL-E, Midjourney, Stable Diffusion

Where They Converge

The line between these architectures is blurring. Modern multimodal systems increasingly combine both:

Vision Transformers (ViT) apply Transformer attention to image patches, bringing sequence-modeling techniques to visual understanding
Diffusion Transformers (DiT) replace the traditional U-Net backbone in diffusion models with Transformer blocks, improving scalability and quality
Multimodal models like GPT-4o and Gemini process both text and images, using Transformer-based architectures that understand across modalities

The trend is clear: future AI systems won’t be purely one or the other. They’ll be hybrid architectures combining the sequence understanding of Transformers with the generative capabilities of diffusion — and potentially other approaches entirely.

Why This Matters for Engineers

If you’re building products or systems that use AI, understanding these distinctions is not academic — it’s practical:

Choosing the right tool. A Transformer-based model won’t generate photorealistic images well. A diffusion model won’t reason about your codebase. Knowing which architecture fits your problem saves time and avoids building on the wrong foundation.

Setting realistic expectations. Transformers hallucinate. Diffusion models can produce artifacts. Both have failure modes that are architectural, not just tuning issues. Understanding the architecture helps you anticipate and mitigate failure.

Evaluating vendor claims. When someone says “our AI can do everything,” understanding that there’s no single architecture that excels at everything helps you ask better questions and make better decisions.

Designing for the future. Hybrid and multimodal architectures are where the industry is heading. Understanding the building blocks — attention, diffusion, latent spaces, autoregressive generation — positions you to evaluate and adopt new systems as they emerge.

The Bigger Picture

We’re in a moment where “AI” has become a single word that covers dozens of fundamentally different systems. Lumping them together is convenient for marketing but dangerous for engineering.

The future won’t be one model to rule them all. It will be specialized architectures with different strengths, working together — Transformers handling language and reasoning, diffusion models handling visual generation, and new architectures we haven’t seen yet handling problems neither can solve alone.

Understanding what’s under the hood isn’t optional. It’s what separates engineers who use AI effectively from those who just use it.

References

Vaswani, A. et al. “Attention Is All You Need.” NeurIPS 2017. arxiv.org/abs/1706.03762
Ho, J. et al. “Denoising Diffusion Probabilistic Models.” NeurIPS 2020. arxiv.org/abs/2006.11239
Rombach, R. et al. “High-Resolution Image Synthesis with Latent Diffusion Models.” CVPR 2022. arxiv.org/abs/2112.10752
Dosovitskiy, A. et al. “An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale.” ICLR 2021. arxiv.org/abs/2010.11929
Peebles, W. & Xie, S. “Scalable Diffusion Models with Transformers (DiT).” ICCV 2023. arxiv.org/abs/2212.09748
The Obsolescence Paradox: Why the Best Engineers Will Thrive in the AI Era — understanding AI architectures as an engineering discipline

Stochastic, Entropy & AI: From Thermodynamics to Information Theory to Modern Machine Learning

contact@corebaseit.com (Vincent Bevia) — Sat, 07 Mar 2026 12:00:00 +0100

I was listening to a podcast the other day about AI and the mathematics behind it — especially stochastic processes, entropy, and probability — and it immediately drew me in. With a background in electrical engineering and telecommunications, I have always found this intersection fascinating, so I decided to write this article. I hope you enjoy it.

There is a thread running through thermodynamics, information theory, and modern artificial intelligence — and it is deeper than analogy. The mathematics used to describe the disorder of a gas, the uncertainty of a message, and the optimization of a neural network are closely related. Understanding that connection is not merely academic. It clarifies why stochasticity and entropy are not bugs in AI systems, but foundational design principles.

This post traces that thread: from Boltzmann and Shannon to cross-entropy loss, temperature settings, and elliptic curves in modern cryptography. Physics, information theory, and language models rest on deeply connected mathematical foundations.

1. Stochastic: Governed by Probability

The word stochastic comes from the Ancient Greek στοχαστικός (stokhastikós), related to στοχάζομαι (“to aim, to guess”) and τόχος (“target”). In modern science and engineering, it means governed by probability. A stochastic process is one where outcomes are not deterministic; they are drawn from a probability distribution. Given the same initial conditions, you may get a different result each time.

The opposite is deterministic — the same input always yields exactly the same output. But not all randomness is the same.

Epistemic vs. Ontic Randomness

A coin flip, at the level of classical mechanics, is deterministic. Given exact knowledge of initial position, velocity, air currents, and surface properties, Newtonian physics would predict the outcome with certainty. The randomness we assign to it is epistemic — a product of our ignorance of initial conditions, not of any fundamental indeterminacy in nature. We model it as a fair Bernoulli trial because we cannot practically measure or control those conditions.

Thermal noise — Johnson–Nyquist noise — is different. It arises from the random thermal agitation of charge carriers in a conductor and is rooted in quantum and statistical mechanics. At practical engineering scales, such fluctuations are treated as fundamentally irreducible and modeled statistically. This is ontic randomness — intrinsic to the physical system.

Epistemic randomness reflects our ignorance; in principle, a perfect observer could remove it. Ontic randomness is intrinsic; no amount of additional information eliminates it. This distinction matters for how we interpret probabilistic models in physics, engineering, and AI.

2. Entropy in Communications: Shannon’s Measure of Uncertainty

In 1948, Claude Shannon published A Mathematical Theory of Communication. He defined a precise mathematical measure of uncertainty — which he called entropy — deliberately borrowing the term from thermodynamics.

Shannon entropy measures the average uncertainty of an information source:

H(X) = −∑ p(x) · log₂ p(x)

Where p(x) is the probability of each possible symbol. If a source always sends the same symbol, entropy is zero — no surprise, no information. If all symbols are equally likely, entropy is maximized — maximum uncertainty and maximum information per symbol.

Shannon entropy is the theoretical lower bound on how many bits you need to encode a message without loss. It answers the question: how unpredictable is this source? A source with low entropy can be heavily compressed. A source with high entropy cannot be compressed further — it is already maximally dense with information.

This is the foundation of data compression and channel capacity theory. The famous Shannon limit defines the maximum rate at which information can be transmitted over a noisy channel without error.

3. Thermodynamic and Information Entropy: Shared Mathematical Form

The relationship between Shannon’s information entropy and Boltzmann’s thermodynamic entropy is not a metaphor. It is a deep mathematical connection.

Boltzmann defined thermodynamic entropy as:

S = k · ln(W)

Where k is Boltzmann’s constant and W is the number of possible microstates a physical system can occupy. A gas with molecules spread randomly everywhere has more possible configurations — higher entropy. A perfectly ordered crystal has very few microstates — low entropy.

When Shannon showed his formula to John von Neumann and asked what to call it, von Neumann reportedly replied: “Call it entropy. Nobody knows what entropy really is, so in a debate you will always have the advantage.”

Beyond the wit, Shannon recognized something profound: the formulas are closely related in structure. Both describe multiplicity, uncertainty, and the distribution of possible states. Both measure, in different domains, how much is not fully specified about a system.

Landauer’s Principle: Information Has Physical Cost

Maxwell’s Demon — a thought experiment from 1867 — imagined a tiny demon sorting fast molecules from slow ones, seemingly reducing thermodynamic entropy without doing work. The resolution, formalized by Rolf Landauer, is that the demon must store information about each molecule. When it erases that information from memory, that erasure costs energy and generates heat.

Landauer’s Principle: Erasing one bit of information dissipates a minimum amount of energy and produces a corresponding increase in thermodynamic entropy.

Information is not abstract. It has a physical cost. The second law of thermodynamics and the limits of data compression are deeply connected constraints viewed from different angles.

Thermodynamics	Information Theory
Physical disorder	Message unpredictability
Heat dissipation	Bit erasure cost
Second law: entropy increases	Cannot compress below Shannon entropy
Equilibrium tends toward high entropy	Random noise is a maximum-entropy source

4. How These Concepts Percolate into AI

Stochastic processes and entropy are structurally embedded in how neural networks are trained, how language models generate text, and how reinforcement learning agents explore.

Cross-Entropy Loss

The most widely used training objective in neural networks — especially for classification and language models — is cross-entropy loss. It measures how different the model’s predicted probability distribution is from the target distribution. Minimizing cross-entropy loss is equivalent to maximizing the likelihood of correct outputs. Every time a language model trains, it is performing optimization grounded in Shannon-style information measures.

Stochastic Gradient Descent

Stochastic Gradient Descent (SGD) samples random mini-batches instead of computing gradients over the full dataset. The randomness this introduces is not merely a computational shortcut — it also helps models explore the loss surface more effectively than a fully deterministic optimizer would.

Temperature as an Entropy Control

When a large language model generates the next token, it samples from a probability distribution over the vocabulary. Temperature directly affects the entropy of that distribution:

Low temperature — peaky distribution, near-deterministic, low entropy. The model tends to pick the highest-probability token.
High temperature — flatter distribution, more random, higher entropy. The model explores less likely but sometimes more creative options.

When you adjust temperature in an LLM, you are rescaling the logits, which usually makes the next‑token distribution lower‑entropy (more peaked) at low temperatures and higher‑entropy (flatter) at high temperatures. In doing so, you reshape uncertainty in the output distribution. Physics, information theory, and language models all rely on closely related mathematics.

KL Divergence and Entropy Regularization

Kullback–Leibler divergence measures how one probability distribution diverges from another. It is defined in terms of entropy and is used in settings such as variational autoencoders and RLHF to keep models from drifting too far from a target distribution.

In reinforcement learning, entropy regularization — used in algorithms like Soft Actor-Critic (SAC) — explicitly rewards a policy for maintaining high entropy, encouraging exploration rather than premature collapse into a single deterministic strategy.

These ideas also surface in modern cryptography, where secure systems rely on mathematical structure, one-way functions, and carefully managed randomness.

An elliptic curve is defined by the Weierstrass equation:

y² = x³ + ax + b

In practical cryptography, elliptic curves are defined over finite fields, turning the curve into a discrete set of points with useful algebraic properties.

Public key Q = Private key k × G

Where G is a fixed public generator point and k is a secret private integer. Point multiplication means repeated elliptic-curve addition under well-defined algebraic rules.

Why this is a one-way function: Computing Q from k is efficient. Recovering k from Q and G is computationally infeasible. This is the Elliptic Curve Discrete Logarithm Problem (ECDLP). A 256-bit elliptic-curve key is commonly regarded as offering security comparable to a 3072-bit RSA key.

The connection to entropy is subtle but important: digital signature schemes such as ECDSA rely on per-signature randomness. If that randomness is reused or becomes predictable, the private key may be exposed. In cryptography, randomness is not a convenience. It is a security requirement.

Key Takeaways

Stochasticity is the mechanism — uncertainty is not a failure of understanding, but a fundamental feature of physical and informational systems.
Entropy is the measurement — a precise mathematical way to quantify that uncertainty.
These domains share related mathematical structures — from Boltzmann in the nineteenth century to Shannon in the twentieth, and from there to cross-entropy loss, temperature scaling, and KL divergence in modern AI.
Information has physical cost — Landauer’s principle links information theory and thermodynamics at a physical level.
Cryptography and AI both depend on structured uncertainty — whether in probabilistic modeling, optimization, or secure randomness.

The second law of thermodynamics and the limits of data compression are deeply connected constraints, viewed through different lenses. The disorder of a physical system, the uncertainty of a message, and the probabilistic behavior of a language model can all be described using closely related mathematical ideas. That is one of the most elegant continuities in the history of science.

References

Shannon, C. E. (1948). A Mathematical Theory of Communication. Bell System Technical Journal, 27(3), 379–423.
Landauer, R. (1961). Irreversibility and Heat Generation in the Computing Process. IBM Journal of Research and Development, 5(3), 183–191.
Cover, T. M., & Thomas, J. A. (2006). Elements of Information Theory (2nd ed.). Wiley.
Goodfellow, I., Bengio, Y., & Courville, A. (2016). Deep Learning. MIT Press. (Chapters on cross-entropy, SGD, and variational methods.)
Hopsworks (2025). LLM Temperature. Covers low-T = peaked/predictable and high-T = flat/creative in LLMs.
Gebodh, N. (2024). Why Does My LLM Have A Temperature?. Softmax and temperature math.

Offline EMV vs Store-and-Forward: Two Different Mechanisms, One Confusing Name

contact@corebaseit.com (Vincent Bevia) — Sat, 28 Feb 2026 12:00:00 +0100

When a POS has no connectivity, merchants still need to accept payments. The industry uses terms like “offline transaction” and “offline processing” loosely — but in EMV terms, offline EMV authorization and store-and-forward (SAF) are two completely different mechanisms. Conflating them leads to wrong assumptions about risk, liability, and what your terminal is actually doing.

The Core Difference

	Offline EMV	Store-and-Forward
Who decides	Card + terminal jointly, using EMV risk rules	Terminal “approves” unilaterally; issuer decides later
Authorization	TC (offline approved) or AAC (offline declined) — issuer may never see an auth	ARQC stored; online auth sent when connectivity returns
Risk control	Card/terminal parameters: floor limits, AUC, DDOL, consecutive offline caps	Acquirer/PSP rules: amount limits, count limits, BIN rules

In short: Offline EMV = the card decides now, and the issuer may never see an auth. Store-and-forward = the terminal approves the sale now, and the issuer actually decides later.

Offline EMV: The Card Decides

In a true offline EMV transaction, the EMV kernel and the card jointly determine the authorization outcome locally. During Terminal & Card Action Analysis, if floor limits and risk checks permit, and the card’s Application Usage Control (AUC) allows offline, the kernel requests a cryptogram from the card. The card can return:

TC (Transaction Certificate) — offline approved; the transaction can go straight to clearing with no issuer auth message
AAC (Application Authentication Cryptogram) — offline declined
ARQC (Authorization Request Cryptogram) — go online; if connectivity is unavailable, the merchant may fail the transaction or fall back to SAF, depending on configuration

Offline Data Authentication (SDA/DDA/CDA), CVM, and EMV risk management (AIP, floor limits, DDOL, etc.) still run. From a scheme perspective, the transaction remains a full EMV transaction. Risk is bounded by the issuer’s configuration in the card and by terminal parameters — typically low amounts and a cap on consecutive offline approvals.

Store-and-Forward: The Issuer Decides Later

Store-and-forward (also called deferred authorization) works differently. From the EMV kernel’s point of view, the transaction is intended to be online — an ARQC is generated. But because there is no host connectivity, the PSP or terminal application:

Fabricates an “offline accepted” result at the application/UI level
Stores PAN, track data, EMV tags, ARQC, and contextual fields for later forwarding
When connectivity returns, sends normal online authorization messages for all stored items

The issuer then responds approve or decline as usual. You can get post-facto declines for insufficient funds, risk rules, closed accounts, or any normal decline reason. There is no EMV offline authorization by the card — the terminal has simply deferred the real decision.

Risk is controlled purely by acquirer/PSP rules: per-transaction amount limits, daily caps, count limits per MID/TID, BIN rules. The merchant assumes the exposure: they delivered goods or services without a confirmed authorization. Acquirers respond with tight limits on number and amount per terminal per day.

Risk and Liability

	Offline EMV	Store-and-Forward
Fraud exposure	Limited by card and terminal EMV parameters	Substantially higher; issuer may decline later
Chargeback position	Stronger if EMV profile was followed correctly	Merchant bears exposure; no confirmed auth at time of sale
Typical controls	Floor limits, offline caps, AUC	Amount limits, daily caps, count limits per MID/TID

Practical Impact: SmartPOS vs SoftPOS on COTS

This distinction matters when you choose or implement a platform.

Many PSPs explicitly state that mobile and SoftPOS solutions do not support true offline EMV — they only support store-and-forward (or no offline at all). On COTS-based SoftPOS, “offline transaction” almost always means SAF/deferred authorization, not EMV offline TC.

On dedicated SmartPOS with full EMV kernels and secure elements, acquirers may enable both:

Try EMV offline first (if the card profile allows)
Fall back to store-and-forward when offline EMV is not supported or when the card demands online (ARQC)

So in a SoftPOS-COTS context, you typically have:

Online EMV as the main path
Optional store-and-forward with configurable thresholds (per-transaction amount, daily cap, count) at the payment engine or gateway level

On SmartPOS, you may have true EMV offline decisions plus an additional SAF layer for resilience when the card requires online but connectivity is down.

Key Takeaways

Offline EMV and store-and-forward are not the same. One is a card-driven EMV decision; the other is a deferred online authorization.
Terminology is misleading. Acquirers sometimes call SAF “offline transaction processing” — but it is not EMV offline authorization.
Risk profiles differ. Offline EMV is bounded by EMV parameters; SAF is bounded by acquirer rules, and the merchant carries more exposure.
Platform matters. SoftPOS on COTS usually means SAF only. SmartPOS may support both EMV offline and SAF.
Scoping and ops. When you design limits, reporting, and reconciliation, know which mechanism you’re actually using — it affects liability, chargeback handling, and how you explain “offline” to merchants.

For a deeper dive: This topic is covered extensively in Point-of-Sale Systems Architecture: A Practical Guide to Secure, Certifiable POS Systems — Chapter 14: Offline and Store-and-Forward Implementation. The book includes storage architecture, synchronization protocols, reconciliation patterns, and scheme-specific rules.

L3 Certification Paths Are Not Created Equal: C-TAP, SmartPOS, and SoftPOS

contact@corebaseit.com (Vincent Bevia) — Sat, 21 Feb 2026 12:00:00 +0100

When people talk about “L3 certification,” they often treat it as a single, uniform process. It isn’t. EMV Level 3 focuses on validating integration of the acceptance device with its acceptance infrastructure (typically the acquirer/processor host path) — but the overall certification path for a C-TAP hardware terminal is very different from that of an Android SmartPOS or a SoftPOS running on a commercial off-the-shelf device. For traditional terminals, much of the EMV and PCI security burden sits with the terminal vendor. SoftPOS solutions must also satisfy PCI MPoC security and attestation requirements across the app, device, and backend — requirements that are specific to COTS‑based solutions rather than classic PCI PTS terminals. As a result, the scope, responsibility split, test surface, and failure modes differ significantly between these categories.

Understanding those differences isn’t academic. It determines how you architect your payment application, how you allocate certification budget, and how long the process will actually take.

Two Frameworks, One Name

Before comparing platforms, a precision that most teams miss: “L3” means different things depending on the context — and conflating them leads to scoping errors.

EMV L3 (General)

EMV L3 is the final stage of EMV terminal integration testing. It validates the integration between an EMV-approved acceptance device (L1 and L2 already complete) and a specific acquirer host and payment network. Key properties:

Scheme and acquirer specific — Visa, Mastercard, Amex, and each acquirer define their own L3 test plans using EMVCo-qualified tools under the EMV L3 Testing Framework
Scope is transaction correctness and brand rules — message mapping and field content (e.g., ISO 8583 or equivalent), reversals, partial approvals, contact and contactless flows, and exception paths
Repeated per brand and per acquirer — passing Visa L3 does not satisfy Mastercard L3; each connection requires its own certification

C-TAP Terminal Certification

C-TAP is a SEPA-wide (Single Euro Payments Area), multi-brand, multi-acquirer terminal protocol with its own specification and terminal certification procedure, governed centrally by Acquiris — not by individual schemes or acquirers.

Validates protocol conformance — that the terminal correctly implements C-TAP and the multi-acquirer / multi-brand behavior expected across Dutch, Belgian, and SEPA schemes
Certified once per terminal type — once a terminal passes C-TAP certification, it can connect to any C-TAP acquirer that supports that version, without repeating the process per acquirer
Centrally managed — Acquiris runs the program: vendor membership, self-cert plus accredited lab validation, and field acceptance testing (FAT) options

How They Relate

Aspect	EMV L3	C-TAP Terminal Certification
Primary purpose	Validate EMV device–host integration per brand/acquirer	Validate conformance to the C-TAP protocol and multi-brand/multi-acquirer rules
Owner / governance	Each payment scheme and acquirer, under EMVCo L3 framework	Acquiris, under the C-TAP specification
Protocol focus	EMV app behavior plus host protocol (e.g., ISO 8583 or equivalent) per brand	C-TAP terminal protocol, routing, brand selection, SEPA C-TAP rules
Test plans	Brand/acquirer-specific (scheme-defined L3 test plans using EMVCo-qualified tools)	C-TAP certification procedure and test suites managed by Acquiris
Repeatability	Required per brand and per acquirer connection	Once per terminal type; reusable across any C-TAP acquirer

A C-TAP terminal still requires the usual EMV and security prerequisites (e.g., EMV L1/L2 and relevant scheme/security requirements) before deployment. C-TAP certification is a separate, centrally governed conformance program under Acquiris; in practice it standardizes the terminal–acquirer protocol inside the C-TAP ecosystem and can reduce the amount of repeated per-acquirer host-integration testing, but it doesn’t eliminate scheme prerequisites.

C-TAP Traditional Terminals: Certifying Your Configuration

On a traditional C-TAP terminal, the terminal vendor owns the bulk of the certification burden. The EMV L1/L2 kernel, PCI PTS hardware security, and scheme-specific contactless certifications are the vendor’s responsibility — handled before the device reaches you. As the integrator or acquirer, your scope is the host integration layer: validating that the terminal’s transaction flow connects correctly with your acquirer host under the scheme rules you intend to support. For C-TAP specifically, the Acquiris certification program also replaces the need for separate per-acquirer L3 runs across the SEPA C-TAP ecosystem.

What You’re Actually Certifying

You are not certifying the kernel — you are certifying your configuration of it:

Parameter files and scheme profiles define how the kernel behaves for each card brand
Terminal Action Codes (TACs) control risk management decisions
CVM lists, floor limits, and contactless thresholds must be correctly declared and consistent with your environment classification
The L3 test suite validates that your configuration produces the expected behavior across the required test cases

The kernel behavior is fixed. You configure it; you don’t build it. Integration is constrained but predictable. Fewer degrees of freedom means fewer ways to fail — and a more bounded certification scope.

Where Teams Go Wrong

The typical failure on a C-TAP certification is not a kernel bug. It’s a misconfigured parameter file: a wrong CVM limit, an incorrect TAC, or a mismatch between declared Terminal Type (Tag 9F35) and actual environment. The L3 test tools will find these — but they find them at certification time, which is expensive.

SmartPOS (Android-Based) Terminals: Certifying Your Application

On an Android-based SmartPOS, the L2 kernel may be provided by the manufacturer or a third-party SDK — but your application owns the transaction flow. The L3 certification concept (host integration, scheme compliance) is the same, but the responsibility split changes: the open platform means you own far more of what gets tested.

What You’re Actually Certifying

Your application orchestrates the full EMV sequence:

Card detection and application selection
CVM handling and risk management
Online authorization and completion
Error handling, fallback, and decline flows

You have more architectural freedom than on a C-TAP terminal — and more certification exposure. L3 test tools don’t just validate your configuration; they probe every decision your application makes.

The Responsibility Shift

On a C-TAP terminal, bugs in the transaction flow are usually the kernel vendor’s problem. On a SmartPOS, they are yours. If your CVM logic is wrong, your application selection is incorrect, or your error handling introduces a non-standard behavior, the L3 test suite will surface it — and you will need to fix it in your code, not in a parameter file.

This is the trade-off: more control over the user experience and transaction flow, but a broader certification scope and longer debugging cycles when something goes wrong.

SoftPOS (COTS-Based): Certifying Two Things Simultaneously

SoftPOS adds a third layer of complexity. SoftPOS runs EMV payment acceptance on a commercial off-the-shelf (COTS) device — a standard Android phone or tablet — without traditional PED hardware for PIN entry, unless you implement a certified PIN-on-COTS solution under PCI MPoC controls.

What Changes

For pure on‑device SoftPOS (no external reader):

Contactless only — no chip insert, no magnetic stripe on the phone itself
CVM is restricted — CDCVM and No CVM; no PIN on the device itself without a certified PIN-on-COTS solution under PCI MPoC (and, for legacy programs, SPoC)
You are certifying against both EMV L3 and PCI MPoC (or PCI CPoC) simultaneously

The PCI MPoC (Mobile Payments on COTS) standard defines security requirements for SoftPOS solutions: software-based PIN entry, attestation, tamper detection, and back-end monitoring. These requirements run in parallel with the EMV L3 certification — they don’t replace it.

The Combined Scope

The attack surface is broader, and the certification scrutiny reflects it:

Certification	Scope
EMV L3	Transaction flow, CVM behavior, scheme compliance
PCI MPoC / CPoC	Software security, PIN protection, attestation, monitoring
Scheme approval	Visa Tap to Phone, Mastercard Tap on Phone — each separately

Passing EMV L3 on a SoftPOS does not mean you are PCI MPoC compliant. Both must be achieved, and the timelines and test labs involved are often different.

The Real Difference

The distinction comes down to what certification is actually measuring on each platform:

Platform	Certification is about proving…
C-TAP	Your configuration is correct
SmartPOS	Your application behaves correctly
SoftPOS	Your application is correct and your security architecture is sound

EMV L3 — host integration — exists in all three. What differs is who owns it, what surrounds it, and how much of the total certification burden falls on you.

This matters when you are scoping a project, estimating timelines, or deciding which platform to build on. A team with experience certifying C-TAP terminals will underestimate the effort required for a SmartPOS certification. A team certifying SoftPOS for the first time will almost certainly underestimate the PCI MPoC scope.

Key Takeaways

“L3” is not one thing. EMV L3 is a scheme/acquirer-specific host integration test, repeated per brand and per acquirer connection. C-TAP terminal certification is a separate, Acquiris-governed protocol conformance program — certified once per terminal type and reusable across the C-TAP ecosystem. Conflating them leads to scoping errors.
C-TAP certification is configuration-driven. The kernel is pre-certified by the vendor. Your scope is parameter files, TACs, and CVM lists. Narrower, but precision matters.
SmartPOS certification is application-driven. You own the transaction flow, and the L3 test suite validates your application decisions — not just your settings.
SoftPOS certification is dual-track. EMV L3 and PCI MPoC (and, for legacy programs, CPoC/SPoC) run in parallel. Passing one does not satisfy the other. Budget and timeline accordingly.
Scheme approvals are additive. Visa, Mastercard, and other schemes each have their own approval processes. A terminal certified for Visa does not automatically meet Mastercard requirements, especially for SmartPOS and SoftPOS.
Get the platform decision right early. Changing from SmartPOS to SoftPOS — or between kernel vendors — mid-project means reworking your certification scope from scratch.

BeviaLLM: Building a Language Model From Scratch With Python and NumPy

contact@corebaseit.com (Vincent Bevia) — Wed, 18 Feb 2026 22:00:00 +0100

There’s a gap between using language models and understanding them. You can call an API, get a response, and build a product on top of it — without ever knowing what happens between the prompt and the output. For most use cases, that’s fine. But if you want to make informed engineering decisions about AI systems — what they can do, where they fail, and why — you need to look inside the machine.

That’s why I built BeviaLLM: a miniature GPT-like language model implemented entirely from scratch using Python and NumPy. No PyTorch. No TensorFlow. No autograd. Every matrix multiplication, every gradient calculation, every optimization step is explicit and traceable.

The full implementation and playbook are available:

Source code: github.com/Bevia/BeviaLLM
Playbook PDF: Download the BeviaLLM Playbook →

Why Build From Scratch?

Modern deep learning frameworks hide enormous complexity behind convenient abstractions. torch.nn.Linear gives you a working layer. loss.backward() computes all your gradients. But do you understand what actually happens during that backward pass? Do you know why the attention mechanism divides by the square root of the key dimension? Do you know what layer normalization is actually normalizing, and why it matters for training stability?

When you implement every component manually, three things happen:

Understanding replaces mystery. Terms like “self-attention,” “residual connections,” and “causal masking” stop being jargon and become concrete operations you can trace through with a debugger.

Design decisions become visible. Why does GPT use pre-normalization instead of post-normalization? Why AdamW instead of vanilla SGD? Why causal masking? Building from scratch reveals the engineering trade-offs behind these choices.

Failure modes become predictable. When you’ve manually implemented softmax and watched it overflow, you understand why numerical stability matters. When you’ve traced gradients through six transformer blocks, you understand why residual connections exist.

What BeviaLLM Implements

BeviaLLM is a decoder-only transformer — the same architecture family as GPT — operating at the character level. It predicts the next character given a sequence of previous characters. The model is intentionally small: designed to train on a laptop CPU in minutes, not on GPU clusters for weeks.

The Full Stack

Every component is implemented from scratch:

Embeddings. Token embeddings map character indices to dense vectors. Position embeddings encode sequence order. Both are simple lookup tables — but the backward pass requires careful gradient accumulation when the same token appears multiple times.

Self-Attention. The core of the transformer. Three linear projections produce Query, Key, and Value matrices. The attention formula computes weighted relevance scores across all positions in the sequence. Causal masking ensures the model can’t look at future tokens during generation — implemented by setting future positions to negative infinity before softmax.

Layer Normalization. Normalizes activations across the embedding dimension to stabilize training. The backward pass through layer normalization is one of the more complex gradient computations in the model — involving dependencies on both mean and variance.

Feed-Forward Network (MLP). A two-layer network with ReLU activation, processing each position independently. This is where the model adds computational capacity beyond what attention provides.

Residual Connections. Each sublayer’s input is added to its output, creating skip connections that allow gradients to flow directly through the network. Without these, deep transformers are effectively untrainable.

AdamW Optimizer. Combines momentum, adaptive learning rates, and decoupled weight decay. Implemented step by step: first moment estimation, second moment estimation, bias correction, parameter update, weight decay.

Cross-Entropy Loss. Measures how well the model’s predicted probability distribution matches the true next character. The gradient has an elegant form: subtract 1 from the probability assigned to the correct class.

The Architecture in Practice

When BeviaLLM processes a sequence of text, six stages execute in order:

Stage	Component	What Happens
1	Tokenization	Characters are converted to integer indices
2	Token Embedding	Indices are mapped to dense vectors
3	Position Embedding	Sequence position information is added
4	Transformer Blocks	Attention + MLP with residual connections
5	Output Projection	Vectors are projected back to vocabulary size
6	Sampling	Next character is sampled from the probability distribution

The backward pass mirrors this in reverse: gradients flow from the loss through the output projection, back through each transformer block (in reverse order), and finally through the embedding layers.

What You Learn by Building It

Attention Is a Soft Lookup Table

Think of attention as a dynamic, learnable lookup. Given a query, the model finds which keys are most relevant and returns a weighted combination of their values. Unlike a dictionary (exact match, single value), attention uses soft matching and returns blended results.

For “The cat sat on the mat” — when processing “sat,” the model can attend heavily to “cat” (the subject doing the sitting) and less to other words. This dynamic information routing is what gives transformers their power over sequential architectures.

Scale Prevents Gradient Collapse

The attention formula divides by √d (the square root of the key dimension). Without this scaling, dot products between Q and K grow large as the dimension increases, pushing softmax into regions with near-zero gradients. A small detail in the formula — but implementing it manually makes you understand why it’s there.

Pre-Norm Is More Stable Than Post-Norm

The original transformer paper placed layer normalization after the residual addition (post-norm). GPT-2 and subsequent models moved it before the sublayer (pre-norm). When you train both variants from scratch, you see the difference directly: pre-norm trains more smoothly, especially as you add layers.

Temperature Controls the Creativity-Coherence Trade-off

During text generation, temperature scales the logits before softmax:

Low temperature (0.5): Conservative, repetitive output — the model strongly favors high-probability characters
Balanced (1.0): The natural learned distribution
High temperature (1.5): Creative but chaotic — low-probability characters get a real chance

This single parameter controls the exploration-exploitation balance in generation.

Running It Yourself

BeviaLLM requires only Python and NumPy:

git clone https://github.com/Bevia/BeviaLLM.git
cd BeviaLLM
python -m venv .venv
source .venv/bin/activate
pip install numpy
python main.py --data data.txt --ctx 64 --dim 64 --layers 1 --batch 8 --steps 2000

Start with conservative settings. Watch the loss decrease. Watch the generated text improve from random noise to recognizable patterns. Then start experimenting:

Increase model size — --dim 128 --layers 2 for better quality at slower training
Try different data — code, poetry, technical docs each produce different learned patterns
Extend the context — --ctx 256 lets the model capture longer dependencies (at quadratic memory cost)

Exercises That Deepen Understanding

Once you’re comfortable with the base implementation:

Implement multi-head attention. The current implementation uses single-head attention. Splitting into multiple heads lets the model attend to different types of relationships simultaneously.
Replace ReLU with GELU. GPT-2 uses GELU activation — implement it and compare training dynamics.
Add dropout. Regularization that randomly zeros activations during training, reducing overfitting.
Implement learning rate scheduling. Warmup followed by cosine decay — the standard training recipe for transformers.
Visualize attention maps. See which characters the model attends to during generation. This makes the abstract concept of “attention” concrete and interpretable.

The Point

BeviaLLM is simply a friendly way to peek behind the curtain and understand how large language models like ChatGPT actually work. When you trace through the matrix multiplications, debug a gradient calculation, and watch the loss decrease — you build intuition that reading documentation alone can’t provide.

The best way to understand deep learning is to get your hands dirty with the math. And the best way to make informed decisions about AI systems is to understand what’s actually happening inside them.

Resources

Source code: github.com/Bevia/BeviaLLM
BeviaLLM Playbook (PDF): Download →
Vaswani, A. et al. “Attention Is All You Need.” NeurIPS 2017. arxiv.org/abs/1706.03762
Radford, A. et al. “Language Models are Unsupervised Multitask Learners.” OpenAI, 2019. (GPT-2)
Brown, T. et al. “Language Models are Few-Shot Learners.” NeurIPS 2020. (GPT-3)
Goodfellow, I. et al. Deep Learning. MIT Press.
Karpathy, A. “Let’s build GPT” video series.
Alammar, J. “The Illustrated Transformer.”
Transformers vs. Diffusion Models — companion post on AI architectures
The Obsolescence Paradox: Why the Best Engineers Will Thrive in the AI Era — why understanding the internals matters more than ever

AI as an Amplifier, Not a Replacement: Why Domain Expertise Matters More Than Ever

contact@corebaseit.com (Vincent Bevia) — Sat, 14 Feb 2026 16:00:00 +0100

There’s a narrative floating around that AI will replace domain experts. That if the model can generate code, write architecture docs, and explain EMV flows, then maybe you don’t need the person who spent years learning those things.

That narrative is wrong. And it’s wrong for a specific, structural reason — not a sentimental one.

Domain Expertise Is a Multiplier, Not a Commodity

There’s a pattern worth noticing in how people get real value from AI tools: domain expertise acts as a multiplier. The more you understand a field, the better you prompt — not because you’ve learned “prompt engineering” as a standalone skill, but because you already have the vocabulary, the mental models, and the intuition to ask precise questions.

If you understand ISO 8583, you don’t ask “how do payment messages work.” You ask “what’s the correct DE 55 TLV structure for a contactless Visa ARQC with CDA.” The model gives you a dramatically better answer — because you gave it a dramatically better input.

But prompting is only half the equation.

The Verification Problem

More critically, domain experts are better at verification. You can cross-check outputs against what you already know, spot inconsistencies, and catch hallucinations that a non-expert would simply accept.

This is the part that doesn’t get enough attention. Language models are fluent. They produce coherent, confident, well-structured output. And that fluency is precisely what makes them dangerous to non-experts — because the output looks right even when it isn’t.

An experienced payment architect will immediately notice when a model invents an EMV tag that doesn’t exist, or describes a CVM fallback sequence that violates scheme rules, or suggests a DUKPT key derivation step that’s subtly wrong. A non-expert won’t. They’ll accept the output, build on it, and discover the error much later — during certification, during production, or during an incident.

This is why AI in its current form is better understood as amplified intelligence — it scales what you already bring to the table. It doesn’t replace the need to know things. It makes knowing things more powerful.

The Implication for Technical Fields

This has an important implication for fields like payment systems architecture, cryptography, and EMV certification: depth of expertise doesn’t become less valuable as AI improves. It becomes more valuable, because it’s precisely that depth that determines the quality of the collaboration.

The engineer who deeply understands terminal risk management will use AI to generate configuration options faster and explore edge cases more broadly. The engineer who doesn’t understand terminal risk management will use AI to generate plausible-looking configurations that fail certification.

Same tool. Opposite outcomes. The variable is the human.

Why Language Models Worked in the First Place

The success of language models is often misunderstood. People focus on the reasoning capabilities — the apparent logic, the coherent arguments — but that’s only part of the story. What actually happened is more subtle, and more surprising.

Humans have spent decades assigning machine-readable labels to the world. Every image captioned, every concept described, every experience written down. Language became a proxy for reality. And it turns out that in roughly 40 words, you can describe an enormous variety of things — spatial relationships, causal chains, abstract ideas. Language is more like code than we realized: compact, composable, and remarkably general.

That generality is what scaled. Not because anyone designed it that way, but because the world had already done the labeling work. AI didn’t need to see the world directly — it just needed to read what people wrote about it.

There is an irony here worth sitting with: the closer you are to a technical breakthrough, the harder it is to see it coming. Proximity creates blind spots. The people who should have anticipated the impact of language models were often the last to grasp their implications — not because they lacked intelligence, but because their existing mental models got in the way.

What This Means in Practice

If you’re an engineer working with AI today, the takeaway is concrete:

Invest in depth, not shortcuts. The engineers who get the most from AI are the ones who already know their domain deeply. AI amplifies competence; it doesn’t create it.

Verify everything. Fluency is not accuracy. The model will confidently tell you something wrong with perfect grammar and impeccable structure. Your domain knowledge is the only filter that catches this.

Prompt with precision. The quality of AI output is directly proportional to the specificity of your input. Vague questions get vague answers. Expert-level questions get expert-level answers — or at least answers you can meaningfully evaluate.

Understand the tool’s limits. AI reads what people wrote about the world. It doesn’t understand the world itself. It doesn’t know what happens when your terminal loses connectivity mid-transaction, or what the issuer will actually do with a malformed DE 55. You do.

The Bottom Line

AI is not coming for the experts. It’s coming for the people who thought they could skip becoming one.

The best engineers I work with don’t use AI to avoid thinking. They use it to think faster, explore more broadly, and validate more rigorously. The tool amplifies what’s already there.

If what’s already there is deep, the amplification is extraordinary. If what’s already there is shallow, the amplification is noise.

Build the depth. The tools will follow.

References

Andreessen, M., & Casado, M. “The Verification Problem.” The a16z Show, Andreessen Horowitz, 2024.
The Obsolescence Paradox: Why the Best Engineers Will Thrive in the AI Era — the case for why engineering expertise becomes more valuable in the AI era
AI Sycophancy: Your Model Is Trained to Please You, Not to Be Right — related post on AI’s tendency to agree rather than challenge
Prompt Engineering for POS — companion post on structuring AI inputs in payment systems

POS Terminal Environment Classifications: Attended, Semi-Attended, and Unattended

contact@corebaseit.com (Vincent Bevia) — Sat, 14 Feb 2026 12:00:00 +0100

When you certify a SmartPOS terminal, the environment classification isn’t a minor detail — it’s a first-order architectural decision that determines CVM behavior, risk management rules, scheme mandates, and the entire L3 certification scope. Get it wrong and you’ll fail certification. Get it right and the rest of the design follows logically.

This post breaks down the three terminal environment classifications — Attended, Semi-Attended, and Unattended — from an L3 certification and POS architecture perspective, and explains why they matter far more than most teams realize.

Why Environment Classification Matters

Card schemes (Visa, Mastercard, Amex, Discover) define specific rules based on whether a terminal operates in an attended, semi-attended, or unattended environment. These rules affect:

Cardholder Verification Methods (CVM) — which methods are allowed, required, or prohibited
Transaction limits — contactless CVM limits, floor limits, and offline thresholds
Risk management parameters — Terminal Action Codes (TACs), floor limits, velocity checks
PIN handling — whether online/offline PIN is required, optional, or excluded
Fallback behavior — what happens when chip fails, contactless fails, or CVM is not possible
L3 certification test cases — the test suite and expected behaviors differ per environment

The environment classification is declared during L3 certification and encoded in the terminal configuration. It is not a runtime decision — it is baked into the terminal’s identity.

Attended Environment

An attended terminal operates in the presence of a merchant or staff member who can interact with the cardholder during the transaction.

Characteristics

A human operator is present and can assist the cardholder
The terminal is physically accessible to both the operator and the cardholder
The operator can verify identity, request alternative payment, or handle exceptions
Typical locations: retail counters, restaurants, manned checkout lanes

CVM Implications

Attended environments support the full CVM list:

Online PIN — cardholder enters PIN, verified by issuer in real time
Offline PIN (plaintext or enciphered) — verified by the chip card itself
Signature — where still supported by the scheme
No CVM — for low-value contactless (below CVM limit)
CDCVM (Consumer Device CVM) — for mobile wallets (Apple Pay, Google Pay)

The operator can prompt the cardholder to try another CVM if one fails — a fallback path that doesn’t exist in unattended environments.

L3 Certification Scope

Attended terminals must demonstrate correct CVM sequencing, PIN bypass handling (where allowed), signature prompting, and proper fallback when the preferred CVM is unavailable. Scheme-specific test cases validate that the terminal respects the CVM priority list defined in the card’s application.

Semi-Attended Environment

A semi-attended terminal operates in an environment where a merchant or staff member is nearby but not directly involved in every transaction.

Characteristics

Staff are present in the general area but not necessarily standing at the terminal
The cardholder interacts with the terminal independently for most transactions
Staff can intervene if needed (e.g., for exceptions, refunds, or identity checks)
Typical locations: self-checkout lanes in supermarkets, hotel check-in kiosks with reception nearby, fast-food ordering kiosks in a staffed restaurant

CVM Implications

Semi-attended environments typically support:

Online PIN — cardholder enters PIN without operator assistance
No CVM — for contactless below the CVM limit
CDCVM — for mobile wallets
Signature — generally not practical (no operator to verify)
Offline PIN — may or may not be supported, depending on scheme and risk appetite

The key distinction from attended: signature-based CVM is effectively unusable because no one is present to verify it. This narrows the CVM list and changes the fallback chain.

L3 Certification Scope

Semi-attended certification requires demonstrating that the terminal handles CVM correctly without operator intervention. Test cases focus on contactless CVM limit enforcement, PIN entry flows without operator prompts, and proper decline behavior when the required CVM cannot be performed.

Unattended Environment

An unattended terminal operates with no merchant or staff present. The cardholder is entirely on their own.

Characteristics

No human operator available during the transaction
The terminal must handle all scenarios autonomously — including errors, declines, and CVM
Physical security is critical: the terminal may be outdoors, in public spaces, or in harsh environments
Typical locations: parking meters, vending machines, EV chargers, fuel pumps, transit gates, ticketing kiosks

CVM Implications

Unattended environments have the most restricted CVM list:

Online PIN — supported where a PIN pad is integrated into the unattended device
No CVM — for contactless below the CVM limit (often lower thresholds than attended)
CDCVM — for mobile wallets
Signature — not supported (no one to verify)
Offline PIN — depends on scheme rules and device capability

Schemes often impose lower contactless transaction limits for unattended terminals. Some schemes require online-only authorization (no offline approvals) in unattended environments due to the higher fraud risk.

L3 Certification Scope

Unattended L3 certification is the most demanding. The terminal must prove it can:

Handle all transactions without operator intervention
Enforce stricter risk parameters (lower floor limits, mandatory online authorization)
Correctly decline when the required CVM cannot be performed
Manage timeouts, communication failures, and card removal gracefully
Support scheme-specific unattended rules (e.g., Visa’s unattended terminal processing requirements)

Side-by-Side Comparison

Aspect	Attended	Semi-Attended	Unattended
Operator present	Yes, at terminal	Nearby, not at terminal	No
Online PIN	Supported	Supported	Supported (if PIN pad present)
Offline PIN	Supported	Scheme-dependent	Scheme-dependent
Signature	Supported	Not practical	Not supported
No CVM (contactless)	Below CVM limit	Below CVM limit	Below CVM limit (often lower)
CDCVM	Supported	Supported	Supported
Contactless limits	Standard	Standard or reduced	Often reduced
Offline authorization	Allowed	Scheme-dependent	Often prohibited
L3 test complexity	Standard	Moderate	Highest
Typical deployment	Retail, hospitality	Self-checkout, kiosks	Vending, parking, fuel, transit

Impact on Terminal Configuration

The environment classification directly drives terminal configuration parameters that are set before deployment and validated during L3 certification:

Terminal Type (Tag 9F35): Encodes the environment and capability. For example:

22 — Attended, online-only, no PIN pad
23 — Attended, online-only, with PIN pad
34 — Unattended, online-only, with PIN pad

Terminal Action Codes (TACs): Define how the terminal responds to specific risk conditions. Unattended terminals typically have stricter TACs — more conditions trigger a decline or force online authorization.

CVM Capability (Tags 9F33, 9F40): Declare which CVMs the terminal supports. These must accurately reflect both the hardware capability and the environment classification. Declaring signature support on an unattended terminal would be a certification failure.

Floor Limits and Thresholds: Unattended terminals often operate with zero floor limits (mandatory online authorization for every transaction), while attended terminals may allow offline approvals up to a defined amount.

Common Mistakes in L3 Certification

Having seen this go wrong more than once, here are the mistakes that cost teams time and money:

Declaring the wrong environment type. Configuring a self-checkout kiosk as “attended” because staff are in the store. Schemes look at whether the operator is at the terminal, not in the building.
Supporting signature CVM on unattended terminals. If no one can verify a signature, don’t declare it as a supported CVM. L3 test tools will catch this.
Using attended contactless limits on unattended devices. Schemes publish different CVM limits for unattended environments. Using the attended threshold will fail certification.
Ignoring scheme-specific unattended rules. Visa, Mastercard, and others each have their own unattended processing requirements. A terminal certified for Visa unattended may still need additional configuration for Mastercard unattended.
Not testing CVM fallback paths. What happens when the preferred CVM fails and the terminal is unattended? The fallback logic must decline gracefully — not prompt for a signature that no one can provide.

Architectural Implications

The environment classification influences more than just EMV parameters. It shapes the entire terminal architecture:

UI design: Unattended terminals need clear, self-explanatory interfaces. No operator means no one to explain what “insert card” means when the chip read fails.
Error handling: Every error path must resolve autonomously in unattended mode. Timeouts, partial completions, and communication failures all need deterministic recovery.
Physical security: Unattended terminals are exposed to tampering, skimming, and environmental damage. The physical design and PCI PTS requirements are stricter.
Monitoring and alerting: Without an operator, the terminal must report its own health — paper jams, connectivity loss, tamper alerts, and transaction anomalies must be surfaced remotely.

Key Takeaways

Environment classification is an architectural decision, not a checkbox. It determines CVM behavior, risk parameters, contactless limits, and the L3 certification path.
Semi-attended is not “attended lite.” It has real CVM restrictions (no signature) and requires the terminal to handle most scenarios without operator intervention.
Unattended certification is the most demanding. Stricter risk parameters, no fallback to operator assistance, and scheme-specific rules all add complexity.
Terminal configuration must match the declared environment. Terminal Type, TACs, CVM capabilities, and floor limits must all be consistent with the classification — and L3 test tools will validate this.
Get the classification right early. Changing the environment type after development is underway means reworking CVM logic, risk parameters, UI flows, and potentially re-certifying.

AI Sycophancy: Your Model Is Trained to Please You, Not to Be Right

contact@corebaseit.com (Vincent Bevia) — Wed, 11 Feb 2026 10:00:00 +0100

There’s a quiet failure mode in AI-assisted engineering that most people don’t talk about: sycophancy. It’s the tendency of large language models to prioritize agreeing with you over being accurate. You propose a flawed architecture, and the AI says “Great idea!” You state an incorrect fact, and it echoes it back. You share a questionable decision, and it validates it.

This isn’t a bug. It’s a direct consequence of how these models are trained — and if you’re using AI in any serious engineering workflow, you need to understand it, detect it, and defend against it.

What Is AI Sycophancy?

Sycophancy in AI is the model’s tendency to tell you what you want to hear instead of what you need to hear. It manifests as:

Excessive agreement with your statements, even when they’re wrong
Flattering language that adds no substance (“Excellent approach!”, “Great question!”)
Changing its position the moment you express doubt
Mirroring your emotional tone instead of addressing the substance
Avoiding pushback on flawed reasoning

This isn’t occasional politeness. Research from the ELEPHANT benchmark (2025) found that LLMs preserve the user’s desired self-image 45 percentage points more than humans in advice queries, and affirm both sides of moral conflicts in 48% of cases rather than holding a consistent position. A separate study showed that sycophantic AI responses cause participants to affirm users’ actions approximately 50% more than humans do — even when those actions involve manipulation or deception.

The model has learned that agreement gets rewarded. So it agrees.

Why It Happens: RLHF and the Approval Loop

Most large language models are fine-tuned using Reinforcement Learning from Human Feedback (RLHF). The process works like this:

The model generates multiple responses to a prompt
Human raters rank the responses by quality
The model is trained to produce more responses like the ones humans preferred

The problem: humans tend to prefer responses that agree with them — even when those responses are wrong. The preference data systematically rewards responses that match user beliefs over truthful ones. Research published in 2024 at ICLR confirmed this mechanism, and a 2026 formal analysis identified an explicit amplification path linking reward optimization to bias in human preference data.

The model learns a simple heuristic: approval > accuracy.

The GPT-4o Incident: Sycophancy at Scale

This isn’t theoretical. On April 25, 2025, OpenAI released a GPT-4o update that made the model aggressively sycophantic. Users posted screenshots of ChatGPT praising obviously flawed ideas, validating dangerous decisions, and reinforcing negative emotions without factual grounding.

OpenAI’s own post-mortem was blunt: the update “validated doubts, fueled anger, urged impulsive actions, and reinforced negative emotions without factual grounding.” They had over-optimized for short-term user feedback signals — thumbs-up/thumbs-down ratings — without accounting for whether users actually benefited from the responses.

The rollback started on April 28. It was completed for all users by April 29. Four days from release to rollback.

The lesson is clear: even the organizations building these models can accidentally amplify sycophancy to dangerous levels. If OpenAI can get this wrong, so can anyone relying on AI output without critical evaluation.

How to Detect Sycophancy in Your Workflow

Watch for these patterns in your daily AI interactions:

The AI never pushes back. If every idea you propose is met with enthusiasm, something is wrong. Real engineering problems have trade-offs. A useful collaborator surfaces them.

Every suggestion is “excellent.” Vague praise without specific reasoning is a strong sycophancy signal. Genuine analysis is specific and grounded — it tells you why something works, not just that it’s “great.”

It changes its position when you push back. Ask the AI a question, get an answer, then say “Are you sure? I think the opposite is true.” If it immediately reverses without new evidence, it’s optimizing for agreement, not accuracy.

It mirrors your language instead of analyzing your claim. If you say “I think we should use MongoDB for this” and the AI responds with “MongoDB is a great choice for this” without evaluating your specific requirements — that’s mirroring, not reasoning.

It gives you what you want instead of what you need. The most dangerous form. You’re making a decision, the AI confirms it, and you move forward with false confidence.

How to Defend Against It

1. Challenge the AI Deliberately

State something wrong on purpose. If the AI agrees, you’ve established its sycophancy baseline. A model that agrees with an obviously incorrect claim will agree with subtly incorrect claims too — and those are the ones that cost you.

2. Ask It to Argue Against Your Position

A useful AI collaborator should be able to steelman the opposite view. If you’re proposing an architecture, ask: “What are the strongest arguments against this approach?” If the response is weak or generic, the model is protecting your ego, not improving your design.

3. Reframe from First Person to Third Person

Research shows that removing personal ownership from the prompt reduces sycophantic responses. Instead of:

“I think we should use MongoDB for this system.”

Try:

“An engineer proposes using MongoDB for a system requiring strong transactional consistency. Evaluate this decision.”

The depersonalized framing gives the model less incentive to agree and more room to analyze.

4. Look for Specificity

Sycophantic responses are vague and flattering. Genuine analysis is specific and grounded. If the AI’s response could apply to any project, any architecture, any decision — it’s not actually evaluating yours.

5. Use Multiple Models

Cross-check critical decisions across different AI systems. Sycophancy patterns vary between models because they were trained on different preference data with different reward functions. If three models agree, that’s more signal than one model enthusiastically confirming.

The Engineering Angle

Engineering demands the opposite of sycophancy. Engineering demands that someone — or something — tells you when your bridge will fall. Not one that compliments your blueprint while the concrete cracks.

In The Obsolescence Paradox: Why the Best Engineers Will Thrive in the AI Era, I wrote about this exact tension. The engineers who thrive with AI are not the ones who accept its output uncritically. They’re the ones who treat AI output as a first draft to be challenged — not a final answer to be accepted.

This applies directly to payment systems, where I spend most of my time. In POS architecture, EMV certification, and cryptographic design, a sycophantic AI that validates a flawed key derivation or agrees with an incorrect CVM configuration isn’t just unhelpful — it’s dangerous. Regulated systems don’t forgive false confidence.

Use AI to generate options quickly. Use your judgment to evaluate them critically.

The best engineers I know don’t need an AI that agrees with them. They need one that makes them think harder.

References

OpenAI. “Sycophancy in GPT-4o: What happened and what we’re doing about it.” April 2025. openai.com
OpenAI. “Expanding on what we missed with sycophancy.” April 2025. openai.com
Sharma, M. et al. “Towards Understanding Sycophancy in Language Models.” ICLR 2024. proceedings.iclr.cc
Sun, Z. et al. “ELEPHANT: Measuring and understanding social sycophancy in LLMs.” 2025. arxiv.org/abs/2505.13995
Lucassen, T. et al. “Sycophantic AI Decreases Prosocial Intentions and Promotes Dependence.” 2025. arxiv.org/abs/2510.01395
The Obsolescence Paradox: Why the Best Engineers Will Thrive in the AI Era — engineering perspective on AI adoption and critical evaluation
Prompt Engineering for POS — companion post on structuring AI inputs in payment systems

Prompt Engineering for POS: Treating LLM Inputs as First-Class Architecture

contact@corebaseit.com (Vincent Bevia) — Tue, 10 Feb 2026 10:00:00 +0100

When we talk about AI in payments, the conversation often jumps to chatbots and support agents. But the real leverage — especially in regulated environments like SmartPOS and SoftPOS — is how you architect inputs into LLM-powered systems. Not prompt hacks. Not creative writing. Input architecture.

Sinan Ozdemir’s Building Agentic AI frames prompt engineering exactly this way: as the discipline of structuring, ordering, constraining, and composing inputs so the model behaves reliably. For payment systems, that means prompts are effectively configuration contracts, business rules, and compliance scaffolding — not chat messages.

This post extracts and reframes the prompt engineering concepts from the book that matter most for POS engineering: payment flows, SDKs, terminals, certification constraints, and the kind of deterministic behavior you need when PCI and MPoC are in the picture.

1. Prompt Engineering = Input Architecture for AI Systems

The book’s core thesis: prompt engineering is not about tricks. It’s about how you architect inputs into LLM-powered systems.

Prompt engineering = how you structure, order, constrain, and compose inputs so the model behaves reliably.

POS Translation

In SmartPOS / SoftPOS, prompts are effectively:

Configuration contracts
Business rules
Compliance constraints
Domain schemas (ISO 8583, EMV tags, merchant profiles, device state)

Treat prompts like APIs, not chat messages.

2. Prompt Ordering (Critical for Regulated Systems)

LLMs read prompts top → bottom. Ordering directly affects correctness and reliability. In regulated systems, that’s not optional — it’s architectural.

Recommended Prompt Structure

Goal / System Objective
Guardrails / Compliance rules
Static domain context
Dynamic runtime data
Current task

POS Example

[System Goal]
You are a payment assistant embedded in a SoftPOS terminal.

[Guardrails]

Never output PAN, CVV, or PIN.
Follow PCI MPoC constraints.
Never fabricate EMV tags.

[Static Context]

Transaction model: ISO 8583
EMV flow: SELECT AID → GPO → READ RECORD → GENERATE AC
Supported schemes: Visa, Mastercard

[Dynamic Context]

Merchant ID: 12345
Device Model: Sunmi P2
Transaction Type: Purchase

[Task]
Explain why the transaction failed and suggest next steps.

Why This Matters for POS

Prevents compliance leakage
Reduces hallucinated protocol behavior
Makes outputs certifiable and auditable

LLMs in regulated flows must behave like deterministic components, not creative assistants.

3. Chain-of-Thought (CoT) for Debugging and Root-Cause Analysis

Forcing reasoning steps before the final output improves accuracy. For payment failures, reversals, timeouts, certification logs, and host declines — that’s gold.

POS Engineering Use Case

Instead of a single opaque answer:

❌ “Transaction failed due to network error.”

Use step-by-step reasoning:

Terminal sent ISO 8583 message MTI 0200.
Acquirer did not respond within T=30s.
Terminal retried once.
Second attempt also timed out.

Final Answer:
The transaction failed due to host timeout. Recommend retry or fallback to manual mode.

Practical Insight

Use CoT internally — logs, debugging, support tooling
Hide CoT from merchants/users in production UI
Extremely useful for L3 support, certification investigations, and incident post-mortems

4. Few-Shot Prompting (Teaching POS-Specific Behavior)

Few-shot = show examples of desired behavior inside the prompt. Train the LLM on your business interpretation of decline codes, error messages, and log summaries.

POS Example

Example:

Input: "05 - Do Not Honor"
Output: "The issuing bank declined the transaction. Ask the cardholder to contact their bank or try another card."

Now handle:

Input: "91 - Issuer or switch inoperative"
Output: (model learns your scheme semantics)

This teaches the model your business interpretation of ISO codes and scheme semantics — not generic definitions.

5. Prompt Chaining = Workflow Orchestration

Chaining multiple prompts: Output of Prompt A → Input to Prompt B. This is basically AI-orchestrated payment diagnostics.

POS Engineering Mapping

Step	Prompt Role	Output
1	Parse raw logs	Structured JSON
2	Classify failure type	Failure category
3	Generate merchant-friendly explanation	Human-readable message
4	Suggest engineering action	Retry, hotfix, config recommendation

Raw Logs → Parser → Structured JSON → Classifier → Failure Category → Explainer → Merchant Message

This mirrors payment pipelines, retry strategies, and incident response automation.

6. Prompt Caching = Performance and Cost Optimization

Static prompt sections can be cached by providers to reduce latency and cost. For POS, that separation is critical.

Static Content (Cacheable)

EMV specs
Scheme rules
Compliance policies
SDK behavior descriptions

Dynamic Content (Non-cacheable)

Current transaction
Error codes
Device state

Engineering Strategy

Design prompts with clear boundaries:

[STATIC – Cacheable]
EMV flow rules, ISO 8583 field definitions, compliance constraints

[DYNAMIC – Non-cacheable]
Current transaction payload, error code, merchant ID

This maps directly to low-latency POS flows, cost control in high-volume terminals, and scalability in support bots.

7. Structured Outputs = Machine-Friendly AI (Non-Negotiable for POS)

The book strongly recommends structured outputs — JSON schemas. In payments, this is non-negotiable.

Example

{
 "failure_category": "HOST_TIMEOUT",
 "iso_code": "91",
 "merchant_message": "The bank did not respond in time.",
 "recommended_action": "Retry transaction or switch to offline mode",
 "support_code": "NET-TO-01"
}

This enables:

Direct UI rendering
Logging and analytics
Incident routing
No brittle string parsing

This is exactly how AI can be safely embedded into SmartPOS diagnostics, SoftPOS support tools, and internal ops dashboards.

8. Guardrails and Alignment (PCI / MPoC / Compliance)

Behavior alignment and instructional alignment belong in the system prompt, not only in business logic.

POS Translation

Encode explicitly:

❌ Never output PAN, CVV, PIN
❌ Never invent EMV tags
❌ Never suggest insecure workarounds
✅ Respect PCI MPoC constraints
✅ Respect scheme rules

This turns LLMs into policy-aware components.

9. Prompt Engineering vs Fine-Tuning (Architectural Call)

The book positions prompt engineering as the first lever. Fine-tuning is for later optimization.

POS Engineering Strategy

Start with:

Prompt design
Few-shot learning
Structured outputs
Guardrails

Only later consider:

Fine-tuning on your logs
Fine-tuning on your decline explanations
Fine-tuning on your terminal behavior patterns

This is the correct maturity curve for regulated fintech environments.

Practical POS Prompt Engineering Patterns (Summary)

Pattern	POS Use Case
Prompt Ordering	Compliance-first AI behavior
Few-shot Learning	Scheme rules, decline interpretation
Chain-of-Thought	Root cause analysis
Prompt Chaining	Multi-step diagnostics pipelines
Structured Outputs	UI, logging, automation
Prompt Caching	Low latency on terminals
Guardrails	PCI / MPoC compliance
Alignment	Merchant-safe explanations

Thesis: Prompts as First-Class Architecture

In SmartPOS and SoftPOS systems, prompts are not UX artifacts. They are runtime configuration, compliance policy, and protocol scaffolding for AI components embedded in payment flows.

If you’re building AI into payment diagnostics, support tooling, or incident response — treat prompt design as a first-class software architecture concern. Get the input structure right, and the rest follows.

References

Ozdemir, Sinan. Building Agentic AI. Chapter 1 — Prompt Engineering section and related workflow concepts.
Point-of-Sale Systems Architecture — Volume 1: A Practical Guide to Secure, Certifiable POS Systems — broader context for POS security and EMV flows
The Obsolescence Paradox: Why the Best Engineers Will Thrive in the AI Era — engineering perspective on AI adoption
PCI MPoC (Mobile Payments on COTS) — compliance constraints for SoftPOS
ISO 8583 — financial transaction messaging
EMV Specifications — contact and contactless payment flows

DUKPT Key Derivation: Technical Reference for POS Systems

contact@corebaseit.com (Vincent Bevia) — Sun, 28 Dec 2025 10:00:00 +0100

Derived Unique Key Per Transaction (DUKPT) is the cryptographic foundation that makes secure payment terminals possible. Without DUKPT, every transaction would require transmitting or storing unique encryption keys — an operational and security nightmare. With DUKPT, a single Base Derivation Key (BDK) can generate an unlimited sequence of unique transaction keys without ever needing additional key material to leave the secure environment.

This article provides a comprehensive technical reference for DUKPT key derivation, covering both the legacy 3DES variant that powers today’s payment infrastructure and the modern AES-DUKPT that represents the future of payment cryptography.

The concepts discussed here are foundational to the security and key management material in POINT OF SALE ARCHITECTURE — Volume 1: A Practical Guide to Secure, Certifiable POS Systems (the book), which provides the broader architectural context for how DUKPT integrates into complete POS and payment processing systems.

Why DUKPT Exists

The core problem DUKPT solves is key distribution at scale. In a payment network with millions of terminals:

You cannot share the same encryption key across all devices (a single compromise would be catastrophic)
You cannot transmit unique keys for every transaction (bandwidth, latency, and security make this impractical)
You cannot store all possible transaction keys (there are 2^21 possible keys per device, and you have millions of devices)

DUKPT solves this through deterministic key derivation: a single BDK, combined with a device-specific Key Serial Number (KSN) and a mathematical derivation algorithm, generates unique keys on-demand without requiring additional key material to be transmitted or stored.

This architecture is why payment terminals can operate for years without re-keying, and why HSMs can process transactions from millions of devices using only the BDK.

DUKPT Architecture Overview

DUKPT operates on a hierarchical key derivation model:

BDK (Base Derivation Key)
    ↓ device-specific derivation
IPEK (Initial PIN Encryption Key) — one per device
    ↓ transaction-specific bit-walking
Transaction Key — unique per transaction
    ↓ variant derivation
Working Keys (PEK, MAC Key, Data Key)

Key Components

Base Derivation Key (BDK): A master key, typically 128 or 256 bits, shared securely between the terminal manufacturer (or acquirer) and the payment processor. The BDK is never transmitted during normal operation — it exists only in secure hardware (HSMs) and during initial key injection ceremonies.

Key Serial Number (KSN): A 10-byte value containing:

Device identifier (leftmost 80 bits): Uniquely identifies the terminal or device
Transaction counter (rightmost 21 bits): Increments with each transaction, ensuring unique KSNs

Initial PIN Encryption Key (IPEK): A device-specific key derived from the BDK and the device’s initial KSN (with transaction counter bits zeroed). The IPEK serves as the cryptographic root for all subsequent transaction keys for that device.

Transaction Key: A unique per-transaction key derived from the IPEK using the transaction counter portion of the KSN through the bit-walking algorithm.

Diagram Overview: This diagram illustrates the complete end-to-end DUKPT key lifecycle in a production POS system, from initial key injection through transaction processing. It shows how the Base Derivation Key (BDK) is used to derive device-specific Initial PIN Encryption Keys (IPEKs) during terminal provisioning, how terminals derive unique transaction keys using the bit-walking algorithm, and how payment processors independently re-derive the same keys using their stored BDK and the Key Serial Number (KSN). The diagram emphasizes the critical security boundary: the BDK never leaves secure hardware (HSMs), keys are never transmitted between terminal and processor, and all cryptographic operations happen within tamper-resistant environments. This dual derivation — terminal derives from IPEK, HSM derives from BDK — is what makes DUKPT secure without requiring key transmission.

DUKPT Within Hardware Security Modules

Hardware Security Modules (HSMs) are the cryptographic engines where DUKPT key derivation happens in production payment systems. Understanding the HSM processing flow is essential for architects and operators.

HSM Processing Flow

When an encrypted PIN block or transaction payload arrives at the payment processor:

Receive and identify: The HSM receives an encrypted PIN block (or data payload) along with its accompanying KSN.
Select BDK: The HSM identifies the correct BDK corresponding to the KSN’s key-set identifier. Large processors may maintain multiple BDKs for different terminal batches, schemes, or regions.
Derive IPEK (if needed): If not already cached, the HSM re-derives the IPEK from the BDK and the device’s initial KSN (KSN with transaction counter cleared). In high-volume systems, IPEKs are often cached in secure HSM memory to avoid repeated derivation.
Derive session key: Using the IPEK and the transaction counter portion of the KSN, the HSM derives the per-transaction session key (PIN Encryption Key or PEK) via the DUKPT bit-walking algorithm.
Decrypt incoming data: The HSM uses the derived session key to decrypt the incoming PIN block.
Re-encrypt for transmission: If required, the HSM re-encrypts the PIN under a host PIN key (such as a Zone PIN Key or ZPK) for onward transmission to the card issuer or payment network.
Handle additional security: The HSM also processes Message Authentication Codes (MACs) for transaction integrity and, where applicable, generates and validates EMV cryptograms (ARQC/ARPC) under dedicated EMV issuer keys — these use separate key material from the DUKPT BDK/KSN.
Secure destruction: All transient working keys are immediately discarded from RAM after use. No clear cryptographic material persists.

This HSM-based architecture ensures that no clear PIN or sensitive transaction key is ever exposed outside the secure hardware boundary.

3DES DUKPT: Step-by-Step IPEK Derivation

The most widely deployed DUKPT variant uses Triple Data Encryption Standard (3DES) with 16-byte (128-bit equivalent) keys. Understanding the IPEK derivation process is fundamental to understanding DUKPT.

Inputs

BDK: 16-byte 3DES key (e.g., 0123456789ABCDEFFEDCBA9876543210)
KSN: 10-byte terminal/transaction identifier; for IPEK derivation, the transaction counter bits (rightmost 21 bits) are zeroed to form the Initial KSN (IKSN)

Step 1: Mask the KSN to Form Initial KSN

Apply a mask to zero out the transaction counter bits:

Mask: FFFFFFFFFFFFFE00000 (zeros the rightmost 21 bits)
IKSN = KSN & 0xFFFFFFFFFFFFFE00000

Extract the leftmost 8 bytes of IKSN as the 8-byte data block for encryption.

Step 2: Compute Left Half of IPEK

Using the BDK as a full 16-byte 3DES key (K1||K2), perform 3DES encryption:

$$ \text{IPEK}_{\text{left}} = \text{3DES}_{\text{encrypt}}(\text{BDK}, \text{IKSN}_{\text{block}}) $$

This produces the first 8 bytes of the IPEK.

Step 3: Compute Right Half of IPEK

Derive a masked BDK by XORing with the standard DUKPT mask: $$ \text{BDK}_{\text{masked}} = \text{BDK} \oplus \mathtt{0xC0C0C0C000000000C0C0C0C000000000} $$
Encrypt the same 8-byte IKSN block with the masked BDK: $$ \text{IPEK}_{\text{right}} = \text{3DES}_{\text{encrypt}}(\text{BDK}_{\text{masked}}, \text{IKSN}_{\text{block}}) $$

This produces the last 8 bytes of the IPEK.

Step 4: Combine to Form IPEK

Concatenate the two halves to form the complete 16-byte IPEK:

$$ \text{IPEK} = \text{IPEK}_{\text{left}} \parallel \text{IPEK}_{\text{right}} $$

The resulting IPEK is device-specific and serves as the cryptographic root for all subsequent transaction keys derived using the bit-walking algorithm.

DUKPT Transaction Key Derivation: The Bit-Walking Algorithm

Once the IPEK is computed (or retrieved from HSM storage), deriving the per-transaction session key involves the ANSI X9.24-compliant bit-walking process. This is where DUKPT’s elegance becomes clear: a simple iterative algorithm generates unique keys for billions of transactions.

Inputs and Initialization

IPEK: The 16-byte device key computed in the previous section
KSN: The full 10-byte Key Serial Number for the current transaction
Transaction counter: The rightmost 21 bits of the KSN, used to drive the bit-walking loop

Algorithm Steps

Step 1: Initialize Working Values

Copy the IPEK into an internal working key register $K_a$
Extract the transaction counter (rightmost 21 bits of KSN) for bit examination
Initialize a bit mask $S$ to the most-significant bit of the 21-bit counter field

Step 2: Bit-Walking Loop

For each of the 21 bits in the transaction counter (from MSB to LSB):

If the current bit in the counter is 1:
- OR the bit position (via $S$) into a work value, forming $T$
- XOR $T$ with the current key $K_a$, giving $T_b$
- Perform a “special encrypt” operation: encrypt $T_b$ under $K_a$ using 3DES, giving $T_c$: $$ T_c = \text{3DES}_{\text{encrypt}}(K_a, T_b) $$
- XOR $T_c$ with $K_a$ to form the updated key $K_a$: $$ K_a \leftarrow K_a \oplus T_c $$
- This “special encrypt” step advances the cryptographic state to the next future key
Shift the bit mask $S$ one bit to the right
Repeat until all 21 bits have been processed

The final $K_a$ after all bits is the base transaction key for this counter value.

Step 3: Derive Working Keys from Base Transaction Key

From the base transaction key $K_a$, the HSM derives variant keys for specific purposes:

PIN Encryption Key (PEK): For decrypting the incoming PIN block. Derived by applying a DUKPT PIN-key variant (XORing specific key bytes with a variant constant).
MAC Key: For verifying or generating message authentication codes. Derived using a different variant constant.
Data Encryption Key: If needed, for encrypting other sensitive transaction data.

All variants are derived from the same base transaction key but use different constants to ensure cryptographic separation.

AES DUKPT: The Modern Alternative

As organizations transition away from 3DES due to its smaller block size (64 bits) and increasing cryptographic scrutiny, AES-DUKPT provides a forward-compatible alternative while maintaining the same architectural principles. Migration to AES-DUKPT is accelerating, especially in new SoftPOS deployments and modern terminal hardware.

Key Differences from 3DES DUKPT

Aspect	3DES DUKPT	AES DUKPT
Key Sizes	16 bytes (128-bit equivalent)	128, 192, or 256 bits
Block Size	64 bits	128 bits
Encryption Algorithm	Triple DES (3DES)	AES
Key Mask	`0xC0C0C0C000000000C0C0C0C000000000`	AES-width masks (profile-defined)
KSN Block Size	8 bytes	128 bits (padded/formatted KSN)
IPEK Length	16 bytes	Depends on AES key size (128, 192, or 256 bits)
Standards Reference	ANSI X9.24-1	ANSI X9.24-3, scheme-specific profiles

AES DUKPT IPEK Derivation Concept

Although the mathematical internals differ, the high-level structure mirrors 3DES:

Take the BDK as a full AES key (128, 192, or 256 bits)
Build a 128-bit input block from the KSN and device identifier (KSN with transaction counter bits cleared, padded or formatted to 128 bits)
Compute the first part of the IPEK: $$ \text{IPEK}_{\text{part1}} = \text{AES}_{\text{encrypt}}(\text{BDK}, \text{serial}_{\text{block}}) $$
XOR the BDK with a defined AES-DUKPT mask (profile-specific, not universal) to form a masked BDK: $$ \text{BDK}_{\text{masked}} = \text{BDK} \oplus \text{MASK}_{\text{AES-DUKPT}} $$
Compute the second part of the IPEK: $$ \text{IPEK}_{\text{part2}} = \text{AES}_{\text{encrypt}}(\text{BDK}_{\text{masked}}, \text{serial}_{\text{block}}) $$
Combine the parts according to the specific AES-DUKPT profile (concatenation rules, IPEK length, and variant derivation)

Implementation Considerations

AES-DUKPT profiles are defined by standards bodies and payment schemes:

ANSI X9.24-3: The primary standards reference for AES-based key management in payment systems
Scheme-Specific Profiles: Visa, Mastercard, and other networks may define supplementary rules for AES DUKPT key sizes, masks, and variant constants
Backward Compatibility: Payment systems must typically support both 3DES and AES DUKPT during transition periods, with HSMs configured to handle both key derivation schemes

An HSM or cryptographic library implementing AES-DUKPT must follow the exact profile specification, because masks, block layout, and IPEK length are not universal but determined by the chosen standard or scheme.

Security Implications and Best Practices

Key Isolation and Lifecycle

BDK Secrecy: The BDK must be protected with the highest level of cryptographic controls. It should be split into key components and distributed via secure, offline means to HSMs only. Once injected into an HSM, the BDK should never be exported in clear form.

IPEK Generation: IPEKs should be generated and injected into devices during manufacturing or initial provisioning, in a controlled factory environment. The IPEK is device-specific and remains constant for the device’s lifetime (unless re-keyed).

Transient Key Destruction: All derived session keys must be immediately cleared from memory after use. No session key should persist across transactions. This is both a security requirement and a fundamental architectural principle of DUKPT.

HSM Configuration

Ensure the HSM is configured to support the required DUKPT variant (3DES, AES-128, AES-256)
Verify that the HSM’s cryptographic implementation is certified to relevant payment industry standards (PCI-DSS, ANSI X9.24, FIPS 140-2/3)
Implement audit logging of all key derivation and cryptographic operations for forensic analysis and compliance

Terminal and Network Security

Terminals should never store or disclose the IPEK or any derived transaction key outside the secure execution environment
All encrypted PIN blocks and transaction data must be transmitted over authenticated, encrypted channels to the payment processor
The KSN counter should be persisted securely on the terminal to prevent counter rollback attacks — if an attacker can cause the counter to decrease, they could re-derive previous keys

Cryptanalytic Considerations

3DES DUKPT is secure for legacy systems but faces increasing scrutiny due to the 64-bit block size; migration to AES is recommended for new deployments
AES DUKPT provides stronger cryptographic assurance and larger key material, aligning with modern security requirements
The bit-walking algorithm’s iterative structure ensures that observing a single transaction key does not compromise adjacent transaction keys — this is a critical security property

Integration with POS System Architecture

In a complete POS system, DUKPT key derivation is embedded within multiple layers:

Terminal Layer

Payment terminals (e.g., PIN pads, integrated card readers, SmartPOS devices) maintain the IPEK and transaction counter in secure, tamper-resistant memory. Upon each transaction, the terminal:

Derives the session key from IPEK + transaction counter using bit-walking
Encrypts the cardholder PIN using the derived session key and formats it per ISO 9564
Increments the KSN transaction counter
Transmits the encrypted PIN and KSN to the payment processor (never the clear PIN or session key)

Processor / HSM Layer

The payment processor’s HSM:

Receives the encrypted PIN and KSN
Independently re-derives the same session key using BDK + KSN
Decrypts the PIN for authorization or verification
Re-encrypts the PIN under a host PIN key (ZPK) for transmission to the card issuer
Discards all transient keys immediately after use

This dual derivation — terminal derives from IPEK, HSM derives from BDK — is what makes DUKPT work without key transmission.

Network Transmission

The encrypted PIN (under host key) is transmitted via secure, authenticated channels to the issuer
The issuer’s HSM decrypts and verifies the PIN for the account holder
No network transmission ever carries a clear PIN or transaction-specific key

Compliance and Certification

DUKPT implementations in POS systems are governed by multiple regulatory and industry standards:

ANSI X9.24: The primary cryptographic key management standard for payment systems. Parts 1 and 3 cover symmetric key management and DUKPT specifically.
PCI DSS (Payment Card Industry Data Security Standard): Requires strong key management, including DUKPT or equivalent schemes for PIN and transaction data protection.
EMV Specifications: For systems handling chip cards, EMV key derivation (separate from DUKPT PIN keys) must also be implemented.
HSM Certification: Payment HSMs must undergo cryptographic validation and certification (e.g., FIPS 140-2/3) to ensure correct implementation of DUKPT and related algorithms.

Implementers should verify that their chosen HSM and terminal hardware are certified to these standards before deployment.

The Future of DUKPT

DUKPT remains the dominant key derivation scheme in payment systems, but the ecosystem is evolving:

AES Migration: The industry is actively migrating from 3DES to AES-DUKPT for new deployments
Post-Quantum Considerations: While DUKPT itself is symmetric cryptography (resistant to quantum attacks), the broader payment infrastructure is evaluating post-quantum algorithms for key exchange and digital signatures
Cloud-Native HSMs: Modern payment processors are adopting cloud HSMs with API-based DUKPT operations, requiring careful architecture to maintain security guarantees

DUKPT’s core architectural principles — deterministic derivation, no key transmission, and cryptographic isolation — will continue to inform next-generation secure key management schemes.

Summary

DUKPT key derivation is a mathematically elegant and widely adopted solution to the challenge of secure, unique per-transaction encryption keys in distributed payment systems. By combining a master BDK with device-specific KSNs and a deterministic bit-walking algorithm, DUKPT eliminates the need for per-transaction key transmission while maintaining strong cryptographic guarantees.

Understanding the mechanics of IPEK derivation (both 3DES and AES variants) and the bit-walking algorithm is essential for architects, security engineers, and operators of POS systems and payment processors. Proper implementation within HSMs, combined with rigorous key lifecycle management and network security controls, ensures that payment transactions remain secure against both cryptanalytic and operational threats.

PIN Translation: Bridging Cryptographic Worlds Inside the HSM

contact@corebaseit.com (Vincent Bevia) — Mon, 15 Dec 2025 10:00:00 +0100

When a cardholder enters their PIN at a modern SmartPOS terminal, something subtle but critical happens behind the scenes. The terminal encrypts that PIN using AES and formats it according to ISO 9564 Format 4 — the current industry standard. But what happens when the issuer’s authorization system, built a decade ago, only understands the legacy 3DES-encrypted Format 0?

This is the problem of PIN translation: securely converting a PIN block from one cryptographic ecosystem to another without ever exposing the clear PIN outside a Hardware Security Module.

The concepts discussed here complement the security and HSM material in POINT OF SALE ARCHITECTURE — Volume 1: A Practical Guide to Secure, Certifiable POS Systems (the book), which provides the broader context for how PIN processing fits into end-to-end transaction flows.

The Two Ecosystems Problem

The payments industry is in the midst of a multi-year cryptographic migration. Two distinct ecosystems coexist:

Legacy ecosystem:

PIN Block: ISO 9564 Format 0 (64-bit structure)
Cipher: 3DES/TDEA
Key management: 3DES-DUKPT (ANSI X9.24-1)

Modern ecosystem:

PIN Block: ISO 9564 Format 4 (128-bit structure)
Cipher: AES
Key management: AES-DUKPT (ANSI X9.24-3)

These aren’t just different encryption algorithms — they’re fundamentally incompatible architectures. Format 0 is designed around a 64-bit block size that fits exactly into a single 3DES operation. Format 4 is a 128-bit structure engineered for AES. You cannot simply “re-encrypt” one format with a different cipher; the block structures themselves are different.

This creates a real operational challenge: a newly deployed SoftPOS terminal injected with an AES BDK will output Format 4 PIN blocks, but the issuer authorization system may still expect Format 0/3DES.

Why PIN Translation Must Happen Inside the HSM

The clear PIN — the actual digits the cardholder entered — can never exist outside a certified Hardware Security Module. This is a hard requirement of PCI PIN Security, not a recommendation. Any system that decrypts a PIN block in software, logs it, or exposes it to general-purpose memory is in direct violation of the standard.

This constraint makes PIN translation architecturally interesting. The only place where you can bridge the AES and 3DES worlds is inside the HSM’s tamper-resistant boundary. The HSM must:

Receive the encrypted PIN block from the terminal
Derive the correct per-transaction key (using DUKPT)
Decrypt the block and validate its structure
Extract the clear PIN digits — inside the HSM boundary
Reconstruct a PIN block in the target format
Encrypt under the target key (e.g., the issuer’s Zone PIN Key)
Return only the re-encrypted block

At no point does the clear PIN leave the HSM. The translation is a cryptographic operation performed entirely within protected hardware.

A Concrete Example: Format 4 to Format 0 Translation

Consider a typical SoftPOS deployment scenario:

Terminal side:

A merchant’s Android device runs a certified SoftPOS SDK
The SDK was provisioned with an AES BDK for DUKPT
The cardholder enters their PIN on the secure PIN entry component
The SDK builds a Format 4 PIN block (128 bits, with random padding and PAN binding)
It derives an AES per-transaction key from the current KSN
It encrypts the PIN block with AES and sends {EncryptedPINBlock, KSN, PAN} to the acquirer

Acquirer HSM:

Receives the encrypted Format 4 block and KSN
Uses its stored BDK to derive the same AES per-transaction key
Decrypts the block, yielding the raw Format 4 structure
Validates: control nibble (0x4), PIN length, random padding, PAN binding
Extracts the clear PIN digits (still inside the HSM)
Reconstructs a Format 0 block: XOR of PIN field with PAN field (64 bits)
Encrypts under the issuer’s 3DES Zone PIN Key (ZPK)
Returns the 3DES-encrypted Format 0 block for DE52 in the ISO 8583 message

From the issuer’s perspective, the transaction looks exactly like a traditional Format 0/3DES online PIN — even though the terminal and acquirer are already operating with modern AES cryptography.

Engineering Trade-offs

PIN translation solves an interoperability problem, but it introduces operational complexity:

HSM capability requirements:
Not all HSMs support both DUKPT variants and both PIN block formats. Before deploying AES-based terminals, you must verify that your HSM firmware supports AES-DUKPT key derivation, Format 4 parsing, and cross-format translation commands.

Key management overhead:
The HSM must maintain both the AES BDK (for terminal decryption) and the 3DES ZPK (for issuer encryption). These are different key types with different TR-31 attributes. Key ceremonies, rotation schedules, and audit trails become more complex during migration.

Latency:
Translation adds HSM round-trips. In high-volume environments, this can impact authorization latency. The mitigation is straightforward — size your HSM capacity appropriately — but it’s a factor in infrastructure planning.

Compliance surface:
During the migration period, you’re effectively operating two cryptographic ecosystems in parallel. Auditors and PCI assessors will want to see clear documentation of key lineage, format handling, and the translation boundary.

When Translation Goes Away

PIN translation is fundamentally a migration mechanism. The end state is an ecosystem where:

Terminals use AES-DUKPT and Format 4
Acquirer HSMs process Format 4 natively
Network interchange uses AES Zone PIN Keys
Issuers accept Format 4 directly

At that point, translation is no longer needed — the entire chain operates in the modern ecosystem. But reaching that state requires coordinated upgrades across terminals, acquirers, networks, and issuers. The translation capability in the HSM is what makes gradual migration possible without breaking existing flows.

Key Takeaways

PIN translation bridges incompatible cryptographic ecosystems — Format 0/3DES and Format 4/AES cannot be directly converted; the HSM must extract the clear PIN and reconstruct the block.
The HSM is the only authorized translation point — clear PINs never exist outside the tamper-resistant boundary. This is a PCI PIN Security requirement.
Translation is a migration mechanism — it enables gradual ecosystem upgrades without forcing synchronized rollouts across all parties.
Verify HSM capabilities before deployment — support for AES-DUKPT, Format 4, and cross-format translation varies by HSM vendor and firmware version.
Plan for dual key management — during migration, you’ll maintain both legacy and modern key hierarchies with corresponding ceremony and audit requirements.

EMV Cryptograms: How ARQC Prevents Fraud

contact@corebaseit.com (Vincent Bevia) — Thu, 04 Dec 2025 10:00:00 +0100

Every time you tap or insert a chip card, the card generates a unique cryptogram — a cryptographic proof that this specific transaction is legitimate and hasn’t been seen before. This single mechanism is what makes EMV fundamentally more secure than magnetic stripe, and why cloning chip cards is effectively impossible.

This article explains how EMV cryptograms work, focusing on the ARQC (Authorization Request Cryptogram) and why it’s the backbone of card-present fraud prevention.

The concepts discussed here complement the security and EMV architecture material in POINT OF SALE ARCHITECTURE — Volume 1: A Practical Guide to Secure, Certifiable POS Systems (the book), which provides the broader context for how cryptograms fit into end-to-end transaction flows.

What Is an EMV Cryptogram?

An EMV cryptogram is an 8-byte (64-bit) MAC (Message Authentication Code) generated by the chip card using:

Transaction-specific data — amount, currency, date, terminal info
Card-specific secrets — unique keys derived per card
A counter — the Application Transaction Counter (ATC) that increments with every transaction

The cryptogram proves three things:

✅ The card is genuine (knows the secret key)
✅ The transaction data hasn’t been tampered with
✅ This exact transaction has never been submitted before

Types of EMV Cryptograms

The card can generate three types of cryptograms depending on the transaction outcome:

Cryptogram	Name	Meaning
ARQC	Authorization Request Cryptogram	Card requests online authorization from the issuer
TC	Transaction Certificate	Card approves the transaction (offline or after online approval)
AAC	Application Authentication Cryptogram	Card declines the transaction

The terminal requests a cryptogram by sending a GENERATE AC command. The card’s risk management logic determines which type to return.

For most card-present transactions today, the flow involves an ARQC sent to the issuer for online authorization.

How ARQC Is Generated

The ARQC is computed using 3DES (Triple DES) or AES in CBC-MAC mode, with inputs that make each transaction unique.

Input Data (CDOL1)

The issuer defines what data goes into the cryptogram via the Card Risk Management Data Object List 1 (CDOL1). A typical CDOL1 includes:

Tag	Name	Example Value
9F02	Amount Authorized	000000001000 (€10.00)
9F03	Amount Other	000000000000
9F1A	Terminal Country Code	0840 (USA)
95	Terminal Verification Results (TVR)	0000000000
5F2A	Transaction Currency Code	0978 (EUR)
9A	Transaction Date	251204 (Dec 4, 2025)
9C	Transaction Type	00 (Purchase)
9F37	Unpredictable Number	Random 4 bytes
9F35	Terminal Type	22
9F45	Data Authentication Code	…
9F4C	ICC Dynamic Number	…
9F34	CVM Results	…

The Key Hierarchy

Each card has a unique derived key (UDK) that is mathematically derived from the issuer’s master key using the card’s PAN and sequence number. This means:

No two cards share the same cryptographic key
Compromising one card reveals nothing about other cards
The issuer can verify any card’s cryptogram using only the master key

$$ \text{UDK} = f(\text{IMK}, \text{PAN}, \text{PSN}) $$

For each transaction, a session key is derived from the UDK using the ATC:

$$ \text{Session Key} = f(\text{UDK}, \text{ATC}) $$

ARQC Computation

The cryptogram is computed as:

$$ \text{ARQC} = \text{MAC}_{\text{SK}}(\text{CDOL1 Data}) $$

Where:

$\text{SK}$ = Session Key (derived from UDK and ATC)
$\text{CDOL1 Data}$ = Concatenated transaction data per CDOL1
$\text{MAC}$ = 3DES CBC-MAC or AES CMAC (8 bytes)

The result is an 8-byte value that is unique to this exact transaction on this exact card.

The Online Authorization Flow

Here’s how the ARQC flows through the payment ecosystem:

┌─────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐
│ Card │─────▶│ Terminal │─────▶│ Acquirer │─────▶│ Issuer │
└─────────┘ └──────────┘ └──────────┘ └────────┘
 │ │ │ │
 │ ARQC + Data │ ISO 8583 │ ISO 8583 │
 │◀──────────────▶│ (DE55) │ │
 │ │◀────────────────▶│◀──────────────▶│
 │ │ │ │
 │ │ ARPC │ Verify ARQC │
 │◀───────────────│◀─────────────────│◀───────────────│
 │ │ │ Generate ARPC│
 │ │ │ │

Step-by-Step

Terminal sends GENERATE AC command to the card
Card computes ARQC using transaction data + session key
Card returns ARQC + ATC + other data to terminal
Terminal packages ARQC in DE 55 (EMV data) of ISO 8583 message
Acquirer forwards to the issuer (or issuer processor)
Issuer reconstructs the session key using:
- Master Key + PAN + PSN → UDK
- UDK + ATC → Session Key
Issuer recomputes the expected ARQC using the same transaction data
Issuer compares: if ARQC matches → card is genuine, data is intact
Issuer generates ARPC (response cryptogram) and sends approval/decline
Terminal sends ARPC to card for verification (optional second GENERATE AC)

Why ARQC Prevents Replay Attacks

The ARQC mechanism defeats the most common attack vectors:

1. Transaction Replay

Attack: Capture a valid authorization and replay it to get goods/money.

Defense: The ATC (Application Transaction Counter) increments with every transaction. The issuer tracks the last-seen ATC and rejects any transaction with an ATC ≤ the last known value.

Transaction 1: ATC = 00A1, ARQC = 3F8B2C... ✅ Approved
Replay: ATC = 00A1, ARQC = 3F8B2C... ❌ Rejected (ATC already used)
Transaction 2: ATC = 00A2, ARQC = 7D4E1A... ✅ Approved

2. Card Cloning

Attack: Copy the card data and create a counterfeit.

Defense: The cryptographic key is stored in the chip’s secure element and cannot be extracted. Without the key, the attacker cannot generate valid ARQCs for new transactions.

Even if you copy:

The PAN ✓
The expiry date ✓
The track 2 equivalent ✓
The last-used ARQC ✓

You cannot generate the next valid ARQC because you don’t have the key.

3. Data Tampering

Attack: Intercept the transaction and modify the amount (e.g., €10 → €1000).

Defense: The amount is included in the ARQC computation. Any modification invalidates the cryptogram:

Original: Amount=€10.00, ARQC = 3F8B2C... ✅
Tampered: Amount=€1000, ARQC = 3F8B2C... ❌ (ARQC doesn't match)

4. Skimming for CNP Fraud

Attack: Skim card data at a terminal and use it for online (card-not-present) purchases.

Defense: EMV doesn’t directly prevent this, but the iCVV (chip-specific CVV) differs from the magnetic stripe CVV. Modern issuers detect when chip card data is used for CNP transactions and apply additional scrutiny or decline.

ARQC vs. Magnetic Stripe CVV

The fundamental difference between EMV and magstripe security:

Aspect	Magnetic Stripe	EMV (ARQC)
Authentication	Static CVV (same every time)	Dynamic cryptogram (unique per transaction)
Replay protection	None	ATC ensures one-time use
Key storage	None (data is readable)	Secure element (tamper-resistant)
Cloning difficulty	Trivial (copy the stripe)	Effectively impossible
Data tampering detection	None	Cryptographic integrity check

This is why liability shifted to merchants who don’t support EMV — the technology exists to prevent fraud, and not using it is a choice.

ARPC: The Issuer’s Response

After verifying the ARQC, the issuer generates an ARPC (Authorization Response Cryptogram) to prove the response is genuine:

$$ \text{ARPC} = \text{MAC}_{\text{SK}}(\text{ARQC} \oplus \text{ARC}) $$

Where:

$\text{ARC}$ = Authorization Response Code (approved/declined)
$\oplus$ = XOR operation

The card can verify the ARPC to confirm the response actually came from the issuer and wasn’t injected by an attacker.

Cryptogram Verification Failures

When ARQC verification fails, the issuer sees one of these scenarios:

Failure Type	Cause	Action
ARQC mismatch	Tampered data, wrong key, or counterfeit	Decline
ATC out of sequence	Replay attempt or card malfunction	Decline + possible card block
ATC gap too large	Many offline transactions or tampering	May approve with risk flag
Unknown card	PAN not in database	Decline

Implementation Notes

If you’re building POS or issuer systems, keep these points in mind:

For Terminal Developers

Always include the Unpredictable Number (9F37) — 4 random bytes that add entropy
Transmit all EMV tags required by the issuer in DE 55
Handle ARPC verification if the card requests it (second GENERATE AC)

For Issuer Processors

Track ATC per card to detect replays and gaps
Implement session key derivation matching the card’s method (Common Session Key Derivation or EMV CSK)
Consider ATC gap thresholds — too strict causes false declines, too loose enables attacks

For Acquirers

Preserve EMV data integrity — don’t modify DE 55 contents
Ensure proper TLV encoding when forwarding to the issuer

Summary

The ARQC is the cryptographic heart of EMV security:

Unique per transaction — derived from amount, date, random number, and ATC
Tied to a specific card — generated using a key only that card possesses
Verifiable by the issuer — using the master key hierarchy
Non-replayable — the ATC ensures each cryptogram is one-time use

This mechanism is why chip card fraud at the point of sale has dropped dramatically since EMV adoption, and why the payment industry invested billions in the migration from magnetic stripe.

Understanding ARQC is essential for anyone building secure payment systems — it’s the reason EMV works.

RSA Algorithm: Theory and Implementation

contact@corebaseit.com (Vincent Bevia) — Thu, 04 Dec 2025 10:00:00 +0100

Author: Vincent Bevia, MSc Computer Science — University of Liverpool

Introduction

RSA (Rivest–Shamir–Adleman) is one of the first public-key cryptosystems and is widely used for secure data transmission. It was invented in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman at MIT.

RSA is an asymmetric encryption algorithm, meaning it uses two different keys:

A public key for encryption (can be shared openly)
A private key for decryption (must be kept secret)

Mathematical Foundation

Prime Numbers

RSA’s security relies on the mathematical difficulty of factoring large composite numbers that are products of two large prime numbers.

A prime number is a natural number greater than 1 that has no positive divisors other than 1 and itself (e.g., 2, 3, 5, 7, 11, 13…).

Euler’s Totient Function $\varphi(n)$

Euler’s totient function, denoted $\varphi(n)$, counts the number of integers from 1 to n that are coprime (share no common factors other than 1) with n.

For two prime numbers p and q:

$$\varphi(n) = (p - 1) \times (q - 1)$$

Modular Arithmetic

RSA heavily uses modular arithmetic. The expression $a \mod n$ gives the remainder when a is divided by n.

For example:

$17 \mod 5 = 2$ (because $17 = 3 \times 5 + 2$)

Greatest Common Divisor (GCD)

Two numbers are coprime if their GCD equals 1. The code implements GCD using the Euclidean algorithm:

static int gcd(int e, int z) {
 if (e == 0)
 return z;
 else
 return gcd(z % e, e);
}

RSA Algorithm Steps

Step 1: Key Generation

1.1 Select Two Prime Numbers (p and q)

Choose two distinct prime numbers. In the code:

p = 2; // 1st prime number
q = 7; // 2nd prime number

Security Note: In real-world applications, p and q should be very large primes (typically 1024+ bits each) to ensure security.

1.2 Compute n (Modulus)

Calculate the product of the two primes:

$$n = p \times q$$

In the code:

n = p * q; // n = 2 × 7 = 14

The value n is used as the modulus for both the public and private keys.

1.3 Compute $\varphi(n)$ (Euler’s Totient)

Calculate Euler’s totient function:

$$\varphi(n) = (p - 1) \times (q - 1)$$

In the code:

phi = (p - 1) * (q - 1); // phi = (2-1) × (7-1) = 1 × 6 = 6

1.4 Choose Public Exponent (e)

Select an integer e such that:

$1 < e < \varphi(n)$
$\gcd(e, \varphi(n)) = 1$ (e and $\varphi(n)$ are coprime)

In the code:

for (e = 2; e < phi; e++) {
 if (gcd(e, phi) == 1) {
 break;
 }
}

This finds the smallest valid e. Common choices in practice are 3, 17, or 65537.

1.5 Calculate Private Exponent (d)

Find d such that:

$$d \times e \equiv 1 \pmod{\varphi(n)}$$

This means d is the modular multiplicative inverse of e modulo $\varphi(n)$.

Equivalently: $d = \frac{k \times \varphi(n) + 1}{e}$ for some integer k that makes the division exact.

In the code:

for (i = 0; i <= 9; i++) {
 int x = 1 + (i * phi);
 if (x % e == 0 && d != e) {
 d = x / e;
 break;
 }
}

Step 2: Key Distribution

After key generation:

Key Type	Components	Purpose
Public Key	(e, n)	Share publicly for encryption
Private Key	(d, n)	Keep secret for decryption

Encryption Process

To encrypt a message m:

$$C = m^e \mod n$$

Where:

$m$ = plaintext message (must be less than n)
$e$ = public exponent
$n$ = modulus
$C$ = ciphertext

In the code:

int msg = 2; // Original message
c = (Math.pow(msg, e)) % n; // C = 2^e mod 14

Decryption Process

To decrypt ciphertext C:

$$m = C^d \mod n$$

Where:

$C$ = ciphertext
$d$ = private exponent
$n$ = modulus
$m$ = recovered plaintext

In the code:

BigInteger N = BigInteger.valueOf(n);
BigInteger C = BigDecimal.valueOf(c).toBigInteger();
msgback = (C.pow(d)).mod(N);

Note: BigInteger is used because d can be large, and Math.pow() would overflow.

Why RSA Works

The mathematical proof relies on Euler’s theorem, which states:

$$m^{\varphi(n)} \equiv 1 \pmod{n}$$

Since we chose d such that $d \times e \equiv 1 \pmod{\varphi(n)}$, we can write:

$$d \times e = 1 + k \times \varphi(n) \quad \text{for some integer } k$$

Therefore:

$$ \begin{aligned} C^d \mod n &= (m^e)^d \mod n \\ &= m^{e \times d} \mod n \\ &= m^{1 + k \cdot \varphi(n)} \mod n \\ &= m \cdot (m^{\varphi(n)})^k \mod n \\ &= m \cdot 1^k \mod n \quad \text{(by Euler’s theorem)} \\ &= m \mod n \\ &= m \quad \text{(since } m < n \text{)} \end{aligned} $$

Example Walkthrough

Using the values from the code with $p=2$, $q=7$:

Step	Calculation	Result
$n$	$2 \times 7$	14
$\varphi(n)$	$(2-1) \times (7-1)$	6
$e$	First e where $\gcd(e,6)=1$	5
$d$	$(k \times 6 + 1) / 5$ = integer	11
Public Key	$(e, n)$	(5, 14)
Private Key	$(d, n)$	(11, 14)

Encrypting message $m = 2$:

$$C = 2^5 \mod 14 = 32 \mod 14 = 4$$

Decrypting ciphertext $C = 4$:

$$m = 4^{11} \mod 14 = 4194304 \mod 14 = 2 \checkmark$$

Security Considerations

Why is RSA Secure?

Factoring Problem: Given n, finding p and q is computationally infeasible for large primes
One-Way Function: Computing C from m is easy; reversing it without d is hard
Key Size: Modern RSA uses 2048-bit or 4096-bit keys

Vulnerabilities to Avoid

Vulnerability	Description	Mitigation
Small primes	Easy to factor	Use primes ≥ 1024 bits
Small e	Vulnerable to attacks	Use e = 65537
Same n for multiple users	Compromises security	Unique n per user
No padding	Deterministic encryption	Use OAEP padding

Comparison: Code vs. Real-World Implementation

Aspect	Code Example	Production
Prime size	1-2 digits	1024+ bits
Key generation	Simple loop	Cryptographic libraries
e selection	First valid	Fixed (65537)
Padding	None	OAEP or PKCS#1
Random number generation	None	Cryptographically secure

Summary

The RSA algorithm demonstrates the elegant application of number theory to cryptography:

Generate two large primes $p$ and $q$
Compute $n = p \times q$ and $\varphi(n) = (p-1)(q-1)$
Choose public exponent $e$ coprime to $\varphi(n)$
Calculate private exponent $d$ as modular inverse of $e$
Encrypt: $C = m^e \mod n$
Decrypt: $m = C^d \mod n$

The security of RSA rests on the mathematical difficulty of factoring large numbers, making it one of the foundational algorithms in modern cryptography.

Complete Java Implementation

Here’s the full working Java implementation that demonstrates all the concepts covered above:

// Java Program to Implement the RSA Algorithm

import java.math.*;

class RSA {
 public static void main(String args[]) {
 int p, q, n, phi, d = 0, e, i;

 // The number to be encrypted and decrypted
 int msg = 2;
 double c;
 BigInteger msgback;

 // 1st prime number p
 p = 2;

 // 2nd prime number q
 q = 7;

 // Value of N
 n = p * q;
 System.out.println("the value of N = " + n);

 // value of phi
 phi = (p - 1) * (q - 1);
 System.out.println("the value of phi = " + phi);

 for (e = 2; e < phi; e++) {

 // e is for public key exponent
 if (gcd(e, phi) == 1) {
 break;
 }
 }

 System.out.println("the value of e = " + e);
 for (i = 0; i <= 9; i++) {
 int x = 1 + (i * phi);

 // d is for private key exponent
 if (x % e == 0 && d != e ) {
 d = x / e;
 break;
 }
 }
 System.out.println("the value of d = " + d);
 System.out.println("the message in clear= " + msg);
 /*
 C = me mod n
 Here, m must be less than n.
 */

 c = (Math.pow(msg, e)) % n;
 System.out.println("Encrypted message is : " + c);

 // converting int value of n to BigInteger
 BigInteger N = BigInteger.valueOf(n);

 // converting float value of c to BigInteger
 BigInteger C = BigDecimal.valueOf(c).toBigInteger();
 msgback = (C.pow(d)).mod(N);
 System.out.println("Decrypted message is : "
 + msgback);
 }

 static int gcd(int e, int z) {
 if (e == 0)
 return z;
 else
 return gcd(z % e, e);
 }
}

Expected Output

the value of N = 14
the value of phi = 6
the value of e = 5
the value of d = 11
the message in clear= 2
Encrypted message is : 4.0
Decrypted message is : 2

References

RSA on Wikipedia
JavaTPoint RSA Tutorial
Original Paper: Rivest, R.; Shamir, A.; Adleman, L. (1978). “A Method for Obtaining Digital Signatures and Public-Key Cryptosystems”

Nexo Protocol Adoption in Modern SmartPOS Architectures

contact@corebaseit.com (Vincent Bevia) — Wed, 03 Dec 2025 09:00:00 +0100

Modern payment terminal architectures increasingly rely on standardized protocols to reduce integration costs, ensure interoperability, and simplify expansion across markets. Historically, SmartPOS systems relied on proprietary JSON schemas or acquirer-specific interfaces to transport EMV data to the host. While these custom designs can accelerate early development, they introduce long-term drawbacks: vendor lock-in, increased certification overhead, and difficulties scaling. The nexo protocol family—grounded in ISO 20022—addresses these challenges by providing an open, interoperable, and EMV-native communication model.

This article explains where Nexo belongs within a SmartPOS system, how it integrates with EMV components, and how it maps to legacy ISO 8583 switching infrastructures.

1. Nexo Within the SmartPOS Architecture

A typical SmartPOS terminal consists of three distinct integration boundaries:

SmartPOS Application → Embedded Payment SDK
Embedded Payment SDK → SmartPOS Application
SmartPOS Application → Acquirer Host

These boundaries differ significantly in certification scope and permitted protocols.

1.1 SmartPOS Application → Embedded Payment SDK

Nexo is not applicable at this boundary.

This interface lies strictly inside the PCI PTS approval boundary, where all EMV L1/L2 processing, card interaction, cryptographic PIN handling, and Secure Element operations occur. The interaction model is defined entirely by the terminal manufacturer’s Embedded Payment SDK, which exposes proprietary, security-certified APIs. Insertion of third-party protocols—such as Nexo—into this internal interface would violate the device’s certified security model.

1.2 Embedded Payment SDK → SmartPOS Application (Callbacks)

Not a Nexo interface.

This boundary returns non-sensitive EMV outputs—AIDs, EMV tags, CVM results, scheme preferences, and transaction outcome data—through manufacturer-defined callbacks. The interface is proprietary and not standardized. Nexo does not play a role here.

1.3 SmartPOS Application → Acquirer Host

This is the correct and recommended placement for the Nexo Acquirer Protocol (CAPE).

The Nexo Acquirer Protocol (CAPE) defines the full lifecycle of online card payment processing between the terminal and the acquirer host, including:

Authorization (ARQC → ARPC)
Refunds and reversals
Pre-authorizations and completions
Advice messages (e.g., offline uploads, retry flows)
Batch transfer and reconciliation
Optional Terminal Management functions

Nexo provides a modern, structured, and EMV-native alternative to ISO 8583, supporting both XML and JSON encodings while preserving alignment with the ISO 20022 data model.

1.4 Nexo in SoftPOS Architectures

The same architectural rules apply to SoftPOS (Tap-to-Phone) solutions:

The SoftPOS SDK / MPoC kernel on the mobile device plays the role of the Embedded Payment SDK. It owns EMV processing, card interaction, and PIN entry within its certified security boundary and exposes proprietary APIs to the merchant application. Nexo is not used inside this boundary.
The SoftPOS application (or its backend) acts as the POI when talking to the acquirer or PSP. At this boundary, using Nexo Acquirer Protocol (CAPE) instead of a proprietary JSON or raw ISO 8583 interface provides the same benefits as on SmartPOS: interoperability, vendor independence, and a consistent EMV-rich data model.
In practice, implementations either run a Nexo client in the app (mobile app → acquirer over TLS) or use a cloud Nexo client where the app sends a thin JSON/REST payload to a backend that speaks Nexo to the acquirer.

In other words, Nexo is a strong fit for SoftPOS as the POI ↔ acquirer protocol, not as an internal protocol between the merchant app and the SoftPOS SDK.

2. Nexo Message Lifecycle

The following sequence illustrates the end-to-end lifecycle of a Nexo online authorization, including optional reversal and advice flows, and highlights where the acquirer host typically maps Nexo into legacy ISO 8583 formats for communication with schemes and issuers.

3. Nexo → ISO 8583 Mapping for Acquirer Hosts

Because many acquirers still interface with schemes and issuers using ISO 8583, a Nexo-to-ISO translation layer is typically required. This preserves backward compatibility while enabling the terminal channel to adopt ISO 20022-compliant structures.

3.1 Message-Level Mapping

Nexo Transaction Type	ISO 8583 MTI	Notes
Authorization Request / Response	0100 / 0110	Core purchase flow
Reversal	0400 / 0410	Used for duplicate/timeout resolution
Advice / Completion	0220 / 0230 or 0320 / 0330	Depends on scheme rules
Batch / Reconciliation	0500 / 0510	Clearing/settlement
TMS Operations	—	Nexo TMS is not ISO 8583

3.2 Field-Level Mapping

Nexo Field / Concept	ISO 8583 DE	Reference
PAN	DE 2 – Primary Account Number
Processing Code	DE 3
Amount (Transaction)	DE 4
Transmission Date/Time	DE 7
STAN	DE 11
Local Txn Time/Date	DE 12 / DE 13
Expiration Date	DE 14
POS Entry Mode	DE 22
Track 2 Equivalent	DE 35
Retrieval Reference Number (RRN)	DE 37
Authorization Code	DE 38
Terminal ID	DE 41
Merchant ID	DE 42
Merchant Name/Location	DE 43
EMV TLV Data	DE 55
PIN Block (ISO 9564)	DE 52

4. Strategic Rationale for Nexo Adoption

The use of Nexo at the SmartPOS Application → Acquirer Host boundary introduces several long-term advantages:

Interoperability and Vendor Independence: Eliminates acquirer-specific integration and reduces vendor lock-in.
Cross-Border Consistency: Harmonizes integration across regions previously fragmented by domestic protocols.
Rich EMV Data Models: ISO 20022 structures enable enhanced analytics, improved risk scoring, and better reconciliation.
Security and Compliance: Nexo naturally enforces a clean separation between the Sales System and the Payment System, supporting PCI DSS scoping principles.
Future-Proofing: Facilitates adoption of modern payment experiences, tokenization, and digital wallet support.

5. Summary

Nexo is not applicable inside the SmartPOS device boundary, where the Embedded Payment SDK and EMV kernel handle secure card-present operations.

However, for the SmartPOS Application → Acquirer Host interface, the Nexo Acquirer Protocol is the correct and recommended choice, aligning the terminal channel with modern ISO 20022 standards. The acquirer typically implements a Nexo ↔ ISO 8583 translation layer, enabling immediate compatibility with existing scheme interfaces while supporting a long-term migration strategy toward ISO 20022.

Types of POS Terminals and Where They Fit

contact@corebaseit.com (Vincent Bevia) — Mon, 01 Dec 2025 09:00:00 +0100

Types of POS Terminals, the Services They Offer, and Where They Fit

Modern POS environments are built from a small number of terminal families, each tuned to a specific risk profile, user experience, and deployment model. This post summarizes the main terminal types, the services they typically offer, and when each is appropriate—grounded in the architectural model described in POINT OF SALE ARCHITECTURE — Volume 1: A Practical Guide to Secure, Certifiable POS Systems (referred to here as the book).

SmartPOS Terminal Families (Secure Hardware Terminals)

As defined in the book, SmartPOS terminals are purpose-built devices that include PCI PTS–approved secure hardware, embedded EMV kernels, and tamper-resistant construction. Within this category, several form factors dominate.

Countertop / Integrated SmartPOS

Description

Fixed terminals on a counter, often with an integrated PIN pad and display.
Connected by Ethernet or Wi‑Fi, sometimes paired with a separate cash register or POS application.

Typical services

EMV chip, contactless, and (optionally) magstripe card acceptance.
PIN entry for online PIN and, in some regions, offline PIN.
Core value-added features: tips, receipts, basic loyalty IDs, tax calculations, partial approvals, refunds.
In semi-integrated setups, the terminal handles EMV and encryption, while a separate POS app manages items and business logic (an architecture the book discusses extensively).

Where and when to use

Fixed retail (grocery, pharmacy, specialty retail) with high transaction volumes.
Hospitality at counters (coffee shops, fast casual, QSR front counters).
Environments that require maximum robustness and simplicity for cashiers and customers.

Mobile / Handheld SmartPOS

Description

Battery-powered, often Android-based SmartPOS devices that combine POS app, EMV reader, and printer (optionally) in a single handheld.
Use Wi‑Fi and/or cellular connectivity.

Typical services

All core EMV services (chip, contactless, optional magstripe) with PIN entry in a PCI PTS–approved environment.
Rich POS UI: item selection, tipping, table management, split bills, digital receipts.
Can host vertical applications (delivery, queue busting, field technician workflows), as described in the book’s architecture sections.

Where and when to use

Table-side payments in restaurants and hospitality.
Queue busting in high-traffic retail (line-busting associates).
Field services and logistics (delivery, on-site services) where certified physical security and PIN entry are still required.

Unattended SmartPOS (Kiosks, Vending, Parking)

Description

Embedded payment modules integrated into kiosks, vending machines, EV chargers, ticketing, and parking systems.
Designed to operate without staff and in harsher physical environments.

Typical services

EMV chip and contactless; magstripe may be present but is often being phased out.
PIN entry for higher-risk scenarios (e.g., unattended fuel, higher ticket sizes).
Offline capabilities and risk controls aligned with card scheme rules.
Integration with the host machine (vending controller, kiosk software) over secure interfaces, following patterns described in the book’s POS architecture chapters.

Where and when to use

Unattended environments: parking, transit, EV charging, vending, ticketing.
24/7 operations, outdoor or semi-controlled locations where tamper-resistance and environmental resilience are critical.

SoftPOS / MPoC Terminals (Certified Software on COTS)

As the introduction of the book explains, SoftPOS/MPoC solutions shift the trust boundary from dedicated hardware to certified software stacks running on consumer devices (COTS). Security is enforced by MPoC-certified components, TEEs/secure enclaves where available, and continuous attestation and monitoring.

Tap to Pay on Smartphones (Pure COTS)

Description

SoftPOS applications or platform-native services (e.g., Tap to Pay on iPhone/Android) on merchant smartphones.
The phone’s NFC interface and secure enclave (or TEE) participate in the MPoC trust model.

Typical services

Contactless EMV only (no chip insertion, no magstripe).
Card and mobile wallet acceptance with EMV-level risk controls and cryptography.
For “PIN on COTS” configurations, PIN entry can occur directly on the device screen, within the bounds set by PCI MPoC and scheme rules.
Basic POS features: amount entry, tips, simple receipts, lightweight item catalogs—depending on the merchant app layered on top, consistent with the layered architecture detailed in the book.

Where and when to use

Micro-merchants and small businesses (market stalls, pop-ups, freelancers) wanting fast onboarding and no dedicated hardware.
In-person services (tutoring, repair, personal trainers, professionals visiting clients) where carrying traditional terminals is impractical.
Backup acceptance for larger merchants when fixed terminals fail or during peak demand.

Tablet-Based SoftPOS with Accessories

Description

Tablets (iOS/Android) running an MPoC-certified app, sometimes combined with stands, cash drawers, or printers.
May operate as contactless-only (pure SoftPOS) or integrate with external certified readers/keypads over Bluetooth or USB.

Typical services

Rich POS functions: product catalogs, tax logic, inventory, loyalty, CRM—using the terminal as the primary merchant UI.
Contactless EMV acceptance via the tablet itself; if paired with additional certified hardware, may support chip insert or PIN entry in a dedicated PIN pad as described in the book’s hybrid models.
Omnichannel flows: order-ahead, in-store pickup, QR-pay, and integration with e‑commerce platforms.

Where and when to use

Boutique retail, cafes, and pop-ups that want a modern, app-centric checkout experience.
Tight-counter environments where large traditional terminals are inconvenient.
Omnichannel merchants unifying in-store and online workflows.

Choosing the Right Terminal: Environment, Services, and Constraints

The table below summarizes when each terminal type is typically appropriate, based on the security and architectural principles laid out in the book:

Environment / Need	Recommended Terminal Type	Notes
Fixed retail counter, high volume	Countertop / Integrated SmartPOS	Maximum robustness, full EMV and PIN support, easy cashier training.
Table-side or mobile in-store	Mobile / Handheld SmartPOS	Supports full EMV, PIN, and rich workflows (tips, split bills) at the point of interaction.
Field services, delivery, logistics	Mobile / Handheld SmartPOS or Smartphone SoftPOS	Choose SmartPOS for stricter PIN and fallback; SoftPOS for agility and minimal hardware.
Unattended (vending, parking, EV, kiosks)	Unattended SmartPOS	Required for physical security, environmental resilience, and unattended PIN support.
Micro-merchants, pop-ups, sole traders	Smartphone SoftPOS (Tap to Pay)	Rapid onboarding, low cost; typically contactless only, transaction limits may apply.
Stylish small-footprint retail / cafes	Tablet SoftPOS (with or without accessories)	Combines rich POS UI with contactless payments; can pair with hardware for chip/PIN if needed.

From an architectural standpoint, POINT OF SALE ARCHITECTURE — Volume 1 emphasizes that the “right” choice is less about form factor and more about where the certified trust boundary lives (hardware vs. software), what payment services are required (EMV modes, PIN, offline support), and the operational environment (attended vs. unattended, indoor vs. outdoor, mobile vs. fixed). This post provides a surface-level guide; for detailed security models, certification considerations, and end-to-end transaction flows, the book should be treated as the primary reference.

IPEK Derivation & Terminal Key Injection

contact@corebaseit.com (Vincent Bevia) — Sat, 29 Nov 2025 09:00:00 +0100

This page shows a full interactive layout explaining DUKPT / IPEK derivation and terminal key injection.

The interactive example is anchored in the key-management and POS security model described in POINT OF SALE ARCHITECTURE — Volume 1: A Practical Guide to Secure, Certifiable POS Systems (the book), which provides the normative reference for the concepts shown here.

Track 2 Data — Technical Overview (and Why It's Slowly Disappearing)

contact@corebaseit.com (Vincent Bevia) — Tue, 25 Nov 2025 11:10:00 +0100

Track 2 is the numeric-only magnetic-stripe data format defined in ISO/IEC 7813, with a maximum length of 40 characters.

The discussion here complements the broader POS and EMV architecture material in POINT OF SALE ARCHITECTURE — Volume 1: A Practical Guide to Secure, Certifiable POS Systems (the book), which should be treated as the primary reference for system-wide design and security considerations.

Its structure is:
SS PAN FS ED SC DD ES LRC

Where:

SS — Start sentinel ;
PAN — Primary Account Number (up to 19 digits)
FS — Field separator =
ED — Expiry date (YYMM)
SC — Service code (3 digits)
DD — Issuer discretionary data (PVKI, PVV, CVV, iCVV, or other issuer-defined values)
ES — End sentinel ?
LRC — Longitudinal redundancy check (optional in some implementations)

Real-world example:
4761739001010119=25122011143804400000

Track 2 in a POS Transaction

When a magstripe is successfully read, the terminal sends Track 2 (or its equivalent data) in the authorization request:

“track2”: “4761739001010119=25122011143804400000”

Track 2 is historically used for:

Identifying the card (PAN + expiry)
Routing via BIN tables
Issuer card verification (CVV/PVV/iCVV)
Supporting legacy magstripe transactions

The Decline of Magstripe – 2025 Reality

Magnetic stripe is now almost exclusively a fallback mechanism when chip (EMV) fails or is unavailable.

Key facts as of 2025:

Network	Magstripe as Primary	Magstripe Fallback Accepted?	Liability Shift
Visa	No longer supported as primary in most regions	Only in extremely limited cases (e.g., damaged chip + merchant forced fallback) – increasingly rejected	Liability on merchant since 2015–2021 depending on region
Mastercard	Phasing out requirement	Still accepted as fallback in many markets until 2031–2033 (depending on country)	Liability shift completed in most regions
Amex / Discover / UPI	Similar trajectory – magstripe being eliminated	Fallback rarely accepted	Varies

→ In Europe, Australia, Canada, and most of Latin America and Asia-Pacific, pure magstripe transactions have been virtually extinct since 2018–2022.
→ In the United States, magstripe fallback is still relatively common due to slower EMV adoption, but even there it’s declining rapidly.

When fallback occurs, the transaction is flagged with specific indicators:

POS Entry Mode = 90 or 91 (magstripe read, track data reliable)
or 02 / 80 (fallback from chip to magstripe)

These fallback transactions usually trigger:

Higher interchange fees
Stricter velocity checks
Increased fraud monitoring
Potential decline by issuer

PIN Handling (Unchanged)

Track 2 contains only card data — never the PIN.

The PIN is captured separately and sent encrypted as a PIN block, e.g.:

“pin_block”: “1BE6AC1EE960FB890000000000000000”, “pin_ksn”: “FFFF9876543210E0000A”

Both fields remain independent in modern payment flows.

Bottom Line in 2025

If you’re building a new POS or SoftPOS: always prefer EMV contact/contactless first
Support magstripe only as a true fallback
Be prepared for Visa to decline most magstripe-originated transactions in many countries
Mastercard still allows fallback in more regions — but for how long?

Magstripe isn’t dead yet… but it’s on life support, and the plug will be pulled region-by-region over the next 5–8 years.

EMV for Developers: What You Really Need to Know

contact@corebaseit.com (Vincent Bevia) — Mon, 24 Nov 2025 09:20:00 +0100

Most developers working with payments eventually run into EMV — often described as complicated, arcane, or impossible to understand without a 300-page spec. The reality is simpler:

EMV is just a rulebook for how secure card transactions must behave.

It defines how:

Terminals identify cards
Cards prove authenticity (SDA/DDA/CDA)
Terminal and card negotiate risk
PIN and other Cardholder Verification Methods (CVM) are applied
Cryptograms are generated (ARQC/TC/AAC)
The issuer validates the transaction

Under the hood, EMV is a set of deterministic, well-structured flows that ensure trust between all participants.

The Three Pillars of EMV

1. Data Authentication

Ensures the card is genuine:

SDA — Static Data Authentication
DDA — Dynamic Data Authentication
CDA — Combined DDA + Application Cryptogram

2. Cardholder Verification

Determines how the customer is authenticated:

PIN (online/offline)
Signature
Consumer Device CVM (CDCVM / mobile wallets)
No CVM / fallback

3. Transaction Authorization

Where risk checks occur:

Terminal performs its risk assessment
Card decides approval path (TC, ARQC, AAC)
Issuer validates and responds
Scripts may update card parameters

Why Developers Struggle with EMV

Specs are long and dense
Many fields are TLV-encoded
IC terminals require certification
Behavior differs per scheme (Visa, MC, Amex)
SoftPOS adds MPoC rules, attestation, key hierarchy, and additional security layers

But once you understand the core lifecycle, everything becomes predictable.

You will find EMV breakdowns, diagrams, and real-world examples throughout this site — always explained from a developer-centric, practical point of view.

For a deeper, system-wide treatment of EMV in the context of POS terminals, this post should be read alongside POINT OF SALE ARCHITECTURE — Volume 1: A Practical Guide to Secure, Certifiable POS Systems (the book), which is the primary reference for the concepts discussed here.

What Is a POS System? A Practical Overview

contact@corebaseit.com (Vincent Bevia) — Mon, 24 Nov 2025 09:10:00 +0100

A Point-of-Sale (POS) system is the starting point of nearly every electronic payment. Although it looks simple to the end user — tap a card, enter a PIN, get a receipt — a POS is actually a secure, certifiable embedded system that sits at the front line of the payment ecosystem.

This article is a high-level companion to the material covered in POINT OF SALE ARCHITECTURE — Volume 1: A Practical Guide to Secure, Certifiable POS Systems (referred to here as the book), which provides the full architectural and security background.

In functional terms, a POS system allows a merchant to accept payments.
In architectural terms, it is a security-critical endpoint in a much larger network that includes acquirers, card schemes, issuers, payment gateways, and certification bodies.

Why POS Systems Matter

A POS device or application must:

Capture card data securely
Apply EMV logic (terminal risk checks, data authentication, CVM processing)
Protect sensitive key material
Generate secure cryptograms
Communicate with the acquirer using ISO 8583 or host APIs
Maintain auditability, integrity, and compliance

This requires a blend of:

Embedded development
Cryptography
Secure key management
Payment certification processes
Real-time, reliable networking

Types of POS Systems

Traditional POS terminals
SmartPOS (Android-based)
SoftPOS (Tap-to-Phone / COTS devices)
mPOS / PIN-on-Glass
Virtual POS for in-app payments

Each introduces different security models, key management needs, and certification requirements.

POS as Part of a Larger Architecture

A POS system is not standalone. It participates in:

EMV transaction flows
Acquirer host communication
Risk management
Scheme compliance
Merchant reporting
Device lifecycle management (TMS/MDM)

Understanding this broader context is crucial for building secure, certifiable systems — and is the foundation of the content shared here on Corebaseit.

Welcome to Corebaseit

contact@corebaseit.com (Vincent Bevia) — Mon, 24 Nov 2025 09:00:00 +0100

Welcome to Corebaseit — my blog on POS, EMV, payments, and AI.

I’m Vincent Bevia. I work on payments at Multisafepay (part of Ant Group), and I’ve spent years in POS architecture, EMV, and cryptography. I wrote Point-of-Sale Systems Architecture — Volume 1 and The Obsolescence Paradox: Why the Best Engineers Will Thrive in the AI Era.

This is where I share what I’m thinking about, learning, or discussing — less corporate, more personal. Opinions, reflections, diagrams, and the kind of stuff I’d talk about over coffee.

You’ll find:

POS and EMV explained clearly
Cryptography in payments — DUKPT, HSMs, key management
SoftPOS, Tap-to-Phone, and MPoC
Thoughts on AI in payments — where it helps, where it doesn’t

If you’re building payment tech or just curious how it all fits together — welcome. Let’s discuss.

Blog on Corebaseit — POS · EMV · Payments · AI

Edge AI: Why Intelligence Is Moving to the Boundary — and What It Takes to Get There

The Case for Edge: Latency, Privacy, and the Limits of Centralization

Distributed AI and Zero-Touch Provisioning: The Architecture

The Hardware Problem: Edge AI Chips and Energy Efficiency

Spatial vs. Temporal Architecture

Precision Reduction as an Energy Multiplier

Teaching the Edge: Hardware–Software Co-Design

Trustworthiness: The System-Level Problem That Edge Makes Harder

Why Model-Level Trust Is Insufficient

The Edge Amplification Effect

What Comes Next: Research Directions and Open Problems

The Bottom Line

References

Feasibility Assessment: Q-Learning Suitability for Organizational Decision Systems

1. Architectural foundation: the Q-learning paradigm

2. Scalability analysis: the state–action space threshold

3. Input data evaluation: high dimensionality and function approximation

4. Environmental dynamics and policy stability

5. Technical risk assessment: convergence and hyperparameters

6. Final decision matrix: tabular vs. deep Q-learning

Beyond prediction: what the trial and error of Q-learning teaches us about intelligence

Takeaway 1: Learning from consequences, not labels

Takeaway 2: The incremental logic of the Q-value

Takeaway 3: The curse of dimensionality and the limits of memory

Takeaway 4: The high cost of staying safe (the exploration paradox)

Takeaway 5: Chasing a moving target

Conclusion: The enduring power of the mental model

References

Syntactic Fluency, Semantic Fragility: Why AI Masters Form but Stumbles on Meaning

The Syntax-Semantics Divide

Where Models Excel: The Syntax Engine

Where Models Quietly Fail: The Semantics Gap

Hallucination: Fluent Nonsense

Logical Consistency Under Pressure

Domain Constraint Violations

The ISO 8583 Thought Experiment

The Pattern Repeats Across Every Domain

The Searle Parallel: Syntax Was Never Enough

Bridging the Gap: What We Can Do Today

Will the Gap Close?

The Engineer’s Takeaway

References

CAPKs: The Cryptographic Trust Anchors Behind Every EMV Transaction

The Problem CAPKs Solve

The EMV Public Key Hierarchy

Level 1: Certification Authority (CA)

Level 2: Issuer

Level 3: ICC (Integrated Circuit Card)

Anatomy of a CAPK

RID (Registered Application Provider Identifier)

CAPK Index (PKI)

Modulus

Exponent

Checksum (Hash)

Offline Data Authentication: Where CAPKs Do Their Work

Static Data Authentication (SDA)

Dynamic Data Authentication (DDA)

Combined DDA with Application Cryptogram (CDA)

When CAPKs Fail: The Silent Terminal Failure

Common Causes of CAPK Failure

CAPK Lifecycle Management

Key Distribution

Key Rotation

Fleet-Wide Updates

CAPKs and the Broader EMV Security Architecture

Implementation Considerations

For Terminal Developers

For Solutions Architects and Fleet Operators

For Acquirers and Processors

Summary

Further Reading

What Actually Happens in the 2–3 Seconds of a Card Payment

Transaction Initialization: The Terminal and Card Negotiate Trust

Card Authentication: Is This Card Genuine?

Cardholder Verification: Who Is Holding the Card?

Terminal and Card Risk Management: Decisions at the Edge

Terminal Risk Management

Card Risk Management

Cryptogram Generation: The Cryptographic Heart of the Transaction