Jacob Marks

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 6 years working with the service before I left Amazon earlier this year. APC launched in August 2022 and runs across mu...

 AWS announced support for Cartes Bancaires in AWS Payment Cryptography. You can read the official announcement here: https://aws.amazon.com/about-aws/whats-new/2026/02/payment-cryptography-cartes-bancaires/ I was not there for the final announcement, but I was heavily involved in the work that made it possible. A large part of that work was audit readiness and making sure the implementation would satisfy the requirements for approval. Cartes Bancaires was still developing their audit program while we were going through the process, which added complexity. I worked directly with Deloitte through the review and was on every vendor call covering progress, evidence, gaps, and what was needed to get across the finish line. Most of the work is not visible from the outside. It was documentation, evidence, validation, follow-up, and making sure assertions matched what could actually be defended during audit. That work is rarely visible, but it is what makes launch possible.

AWS announced AWS Payment Cryptography is now available in the Asia Pacific (Sydney) Region. You can read the official announcement here: https://aws.amazon.com/about-aws/whats-new/2025/12/aws-payment-cryptography-in-sydney/ This was a particularly difficult launch. Not because of one major issue, but because there were a lot of moving pieces all happening at once. Hardware deployment issues, firmware rollout problems, feature dependencies colliding near the finish line, compliance requirements, launch timing, and the normal reality that things rarely line up as cleanly in practice as they do on a plan. A lot of the work near launch was simply making sure everything that needed to happen actually happened, in the right order, without creating new problems somewhere else. Regional expansion for a service like this is never just turning something on in another place. Every assumption around hardware, operations, and readiness gets tested again. Those are usually the hardest launches. Not...

AWS announced the launch of AWS Payment Cryptography this week, and I’ve had the opportunity to lead the service from its earliest definition through production launch. The official AWS announcement is here: https://aws.amazon.com/about-aws/whats-new/2023/06/aws-payment-cryptography/ . This was one of those projects where the hard part was never just building software. The challenge was defining a service that could meet the expectations of payment processors, issuers, and financial institutions who were used to a vastly different interaction model while operating inside the security, compliance, and operational standards required for payment cryptography. My role started at the beginning: taking early customer input, writing the initial business requirements, and helping shape the architecture that would eventually become the service. That meant defining the threat model, establishing the security posture, and making early decisions around control-plane boundaries, data-plane design, ...