The compliance edge of a payments platform

I was technical lead for payments at Indigo Tech Group, a Mindbody company. Indigo has since been renamed Kite Technologies and is now a registered payment facilitator. My work sat on the side of it where moving money stops being an engineering problem and starts being a regulatory one.

What a payment facilitator takes on

Becoming a payment facilitator means taking on obligations a bank would otherwise hold. Before a merchant can process a payment, somebody has to establish that the business is real, that the people behind it are who they claim, and that none of them appear on a sanctions list. That is beneficial ownership verification and screening, and most of it is data work: identity evidence arrives incomplete, entities change shape, and the answer has to hold up months later when somebody asks how you reached it.

The rest of what I worked on had the same character. Card-present processing from terminal communication through to the stored transaction, integrating a processor's cloud API. Webhook subscription management on Lambda and DynamoDB, so external systems learned about payment events in close to real time. A payment component embedded in the core application for card and bank account entry. PCI compliance was a standing constraint on every one of those decisions from the start.

What carried over to claims

Payments taught me the habit I now use on pharmacy claims. The failures that matter are values that look completely plausible and are wrong, in systems where nobody notices until money or a regulator does. A funds transfer that reconciles to the wrong fee, an entity that passes a check it should have failed, a transaction stored in a shape that reads fine until someone asks a question a year later.

So I write tests around the monetary edge cases, and I would rather build a verification step than trust a report.