I have two new open-source projects to announce. Both target the same problem from different angles: making it easier to move payment applications that depend on a hardware HSM onto AWS Payment Cryptography (APC).
- aws-payment-cryptography-hsm-proxy: a Rust TCP proxy that speaks Thales payShield 10K and Futurex Excrypt wire protocols and translates outbound calls to AWS Payment Cryptography.
- aws-payment-cryptography-mcp: a Model Context Protocol server that gives any MCP-compatible AI coding assistant (Claude Code, Codex CLI, Kiro, others) direct, domain-aware access to the APC control plane and data plane, plus embedded knowledge of HSM command sets and PCI PIN compliance rules.
The proxy and the MCP server are designed to be used together, but each is useful on its own.
Why this exists
I was the founding manager for AWS Payment Cryptography and spent 5 years working with the service before I left Amazon earlier this year. APC launched in August 2022 and runs across multiple regions with a large fleet of production HSMs. The manufacturer of those HSMs, Futurex, is an open secret. Adam Cason and David Close from Futurex were crucial to building APC.
In many customer conversations about migration, the same question came up: how do we move our existing application to APC without rewriting it? Most production payment systems were written before any cloud cryptography service existed. They speak directly to a payShield, Atalla/Utimaco, or Futurex HSM, often through library code that has not been touched in a decade. The application is in scope for PCI, the team supporting it is small, and the migration budget does not cover an SDK refactor on top of everything else. Stack that with payShield not being the friendliest technology to work with.
I always wanted to publish a clean answer to that question. It was not something I could build inside the service team. Over the past few months, I have had the time, and Claude has made it practical for one person to do work that would previously have required a small team.
What the proxy does
The proxy is deployed in your environment and sits between the application and the HSM. The application sends the same commands it always has to the new proxy IP address rather than the HSM. The proxy parses commands, maps each command to an APC API call, and returns a response in the wire format the application expects. No application code changes, and it doesn’t matter what the application is: a custom acquiring application, an off-the-shelf payment gateway, BCSS, etc.
The proxy translates payShield or Futurex commands into AWS Payment Cryptography API calls. The application sees no change.
Coverage today is built around the commands that show up in real acquirer and issuer code: PIN translate, PIN verify (IBM 3624 and Visa PVV, both DUKPT and static), MAC (ISO 9797 Alg 1 and 3, CMAC, HMAC, DUKPT MAC), CVV generate and verify, data encrypt and decrypt, ARQC verify, EMV issuer script MAC, and the legacy MAC and CVV variants that appear in older payShield code. The full Thales command matrix and the (smaller) Futurex matrix are in the README.
Thales command documentation is “well leaked,” as someone I know put it to me, and EFTLab has some commands documented publicly. I do not have Futurex command documentation available to build out more complete coverage as it is very controlled material. APC does not support every Thales command and has limited support for issuer use cases, so some commands cannot be mapped.
The proxy supports a passthrough discovery mode. You point it at your real HSM, run a representative set of transactions through your application, and the proxy forwards everything to the real HSM while writing one redacted JSON line per unique command code to a discovery log. The output is the input to the MCP server if you plan to tackle an application refactor.
What the MCP server does
The MCP server is the AI side of the same problem. It exposes the APC control plane and data plane as MCP tools, and ships with embedded knowledge of:
- TR-31 / X9.143 key usage codes and the legal pairings between them
- Thales payShield 10K Legacy and International command codes, with their APC equivalents and notes on which mappings are authoritative versus reference quality based on the data sources I have available to validate them
- Futurex Excrypt Enterprise SSP v.2 command set (authoritative against the General Payment HSM Integration Guide)
- PCI PIN v3.1 requirements that translate to hard stops in the tool layer (illegal PIN format pairs, AES keys with non-CMAC KCV, unknown TR-31 usage codes)
- Modern defaults for new acquirer integrations (AES DUKPT, ISO Format 4, TR-34 for key exchange) with explicit confirmation required for any legacy deviation
There are three workflows the server is built for:
- Greenfield. You are building a new acquirer or processor integration on APC. The AI calls APC directly, explains the key hierarchy as it goes, and refuses to create constructs that violate compliance rules without an explicit override.
- Migration analysis. You show the AI an existing application. It identifies every HSM command in use, maps each to the equivalent APC operation, calls out anything that has no clean equivalent or requires a key import via TR-34, and writes the refactored code.
- Proxy handler authoring. You give the AI the discovery log from the proxy. It returns which commands already have handlers, which need to be written, the APC operation and key type for each, and the file paths to drop the new Rust handlers into.
The third workflow is the one that ties the two projects together. The discovery log is small (one record per unique command, not per transaction) and fits cleanly into an AI coding session as source context.
Status
I want to be specific about what is validated.
Against real AWS Payment Cryptography in us-east-1: 23 live integration tests covering every implemented handler category, plus 12 more covering passthrough, TLS, mTLS, and timeout behavior. Measured latency numbers are in the proxy README. This solution will impact latency but is as thin as possible and written in Rust.
Against a real HSM-dependent client application: not yet. The protocol parsers are built from specification and vendor reference documentation, not from live wire captures. That is the most valuable gap remaining and the hardest one to close on my own. If you have access to a payShield 10K or a Futurex HSM and an application that talks to it, I would like to hear from you, and a GitHub issue describing what you saw is the right way to start.
The MCP server has been used to drive real work, including parts of the build-out of the proxy itself and my CyberChef Payments fork of CyberChef. The testimonial in its README is a quote from Kiro, an AI client, answering directly whether the server actually helped. I included it because the honest answer is "yes, in specific ways," not "this changes everything."
On AI-assisted development
Both projects were built with heavy use of Claude. I want to be clear about what that means and what it does not mean.
Architecture, scope, source selection, what to validate, and what to publish were my decisions. The implementation, the test scaffolding, the documentation drafts, and a substantial amount of the research synthesis were AI-accelerated. Every claim that touches payment cryptography behavior was checked against authoritative vendor or AWS documentation. Where uncertainty remains, the code and the README say so explicitly.
This is the workflow I have settled on after the move from ChatGPT to Claude earlier this year. It is also the workflow I would recommend to anyone in this domain who is trying to ship real work as a small team or as an individual. The domain knowledge has to come from somewhere; the speed comes from the tooling, and I genuinely feel like this project would have taken substantially longer with much lower confidence without the tools.
I want to also acknowledge two other recent payment tools that I discovered kabc.ca by Robert Peng and keylab.cloud/calculator by Thiago Alonso. This is a fairly niche domain and I think it is only right to call out the good work of others even if they are competitor projects. Until very recently, if you wanted tools like these, EFTLab was almost your only bet, and their product is no longer free; not a dig, just reality.
Links
- Proxy: github.com/J8k3/aws-payment-cryptography-hsm-proxy
- MCP server: github.com/J8k3/aws-payment-cryptography-mcp
- Companion project: CyberChef Payments
Issues, PRs, and direct feedback are all welcome, especially from operators who have walked a real HSM migration. If you are evaluating APC and would like to talk through what a migration would look like for your stack, my contact details are on the front page of the site.