Compliance is not a phase you bolt on before launch. It is a set of constraints on your architecture, and the cheapest time to honor them is while you are still drawing boxes. Get the fund flow wrong and you may owe state regulators a license you cannot get in time. Get PCI scope wrong and a single line of JavaScript can drag your whole web stack into an annual audit.
This module is about three gates that sit upstream of code: where cardholder data touches your systems, where you verify who you are dealing with, and whether you are legally allowed to hold and move the money the way you designed. The ledger work from module 4 and the reconciliation timing from module 6 assume you already cleared these gates. We treat them as design inputs, not paperwork.
PCI scope: keep the card data out of your stack
Your PCI obligation scales with how close cardholder data gets to your servers. The practical goal is almost always the same: never let a primary account number (PAN) touch infrastructure you own. If the card data flows only through a PCI DSS compliant processor and never lands in your environment, you can validate against SAQ A, the lightest self-assessment questionnaire.
The mechanics matter here. Under PCI DSS v4.0.1, which took effect March 31, 2025, SAQ A eligibility now turns on two conditions. Every element of the payment page delivered to the customer's browser must originate only and directly from a compliant third-party service provider or processor, and you must confirm your site is not susceptible to script-based attacks that could affect your e-commerce systems.
Redirect versus iframe is an architecture decision
The two common patterns are a full redirect to the processor's hosted page and an embedded iframe served by the processor. Both can qualify for SAQ A, but they are not equal on the new script criterion.
Per PCI SSC FAQ 1588, the script-attack confirmation does not apply to merchants whose page simply redirects the customer to the processor. For embedded payment forms, you must either implement controls aligned with Requirements 6.4.3 and 11.6.1 (script inventory plus change-and-tamper detection) or get written confirmation from your processor that the embedded solution includes those protections.
Worked example: you are choosing between Stripe Checkout (redirect) and an embedded Elements iframe. The redirect keeps the script obligation off your plate entirely. The iframe gives you a smoother flow but now requires you to either run a script-monitoring control across your checkout pages or hold a vendor attestation on file. That is a real engineering and audit cost, and it belongs in the build-versus-buy comparison from module 3, not in a post-launch scramble.
The rule of thumb: collect the smallest amount of card data, in the fewest places, for the shortest time. If you find yourself wanting to "just log the PAN for debugging," stop. That single decision can move you from SAQ A to a full Report on Compliance.
KYC and AML: gates on the people, not the cards
PCI protects card data. KYC (Know Your Customer) and AML (anti money laundering) protect against onboarding the wrong parties and missing illicit flows. These are separate regimes with separate triggers, and they attach to whoever you are taking money from or paying out to.
If you operate a platform that boards other businesses (the payment facilitator or marketplace shape), Visa and Mastercard require you to underwrite each sub-merchant before activating processing. That means verifying the business identity and registration, identifying and verifying beneficial owners, screening against OFAC sanctions lists and the card networks' MATCH list, and checking for prohibited business categories. This is not optional best practice; it is a network rule tied to the liability you take on for every merchant you board.
Where these checks live in the build
Treat onboarding as a state machine, not a form. A sub-merchant or payout recipient moves through submitted, screening, approved, or rejected, and processing is gated on approved. Screening calls (identity verification, beneficial-owner checks, sanctions and MATCH lookups) are asynchronous and can fail or return ambiguous results, so model them like the retries and idempotency work from module 5.
Worked example: a marketplace seller signs up and starts listing within minutes, but your code must hold their first payout until OFAC and beneficial-owner checks clear. If you let funds settle to an unscreened recipient, you have created an AML exposure and likely a network violation in one step. The fix is a hard gate in the ledger: a recipient with screening status other than cleared cannot have a payable balance released, and that invariant is enforced in code, not in a runbook.
Screening is also ongoing. Sanctions lists change, and a recipient who cleared at onboarding can later appear on one. Plan for periodic rescreening and a way to freeze a recipient's payouts without breaking the rest of the ledger.
Fund-flow legality: the question that decides your license
Here is the gate most teams discover too late. Under the federal Bank Secrecy Act, taking in funds to transmit to another person can make you a money transmitter, which means registering with FinCEN and, separately, obtaining a state license in every state where you receive from or send to a resident. That state-by-state licensing is slow and expensive, and you cannot retrofit it the week before launch.
The decision hinges on one thing: do you take custody and control of customer funds, or do they pass through a structure where you are outside the flow? If your processor settles funds and you are never in the money flow, you generally are not a money transmitter. If you receive funds into an account you control and then distribute them, you may be.
The agent-of-the-payee path
Many platforms avoid money transmitter status through the agent-of-the-payee exemption. Broadly, if you collect payments on behalf of a seller under a written contract that designates you as their agent, the seller presents you publicly as a payment recipient, and payment is deemed received by the seller the moment you receive it (releasing the buyer's obligation), then you are collecting for the payee rather than transmitting on the buyer's behalf.
The catch: this exemption is recognized in roughly two dozen states, about 22 allow it outright with a few more case-by-case, not all of them, and the specific conditions vary by state. So "we use agent of the payee" is the start of an analysis, not the end. Your contracts, your public presentation, and your fund-flow timing all have to actually match the exemption you are claiming, in every state you operate in.
Worked example: you assumed your processor's settlement covered you, then a compliance review finds that funds briefly land in an account you control before payout. That custody, even for a day, can flip you into money transmission territory. The architectural fix is to keep funds in a for-benefit-of (FBO) structure your processor or bank partner controls, with you directing distributions rather than holding the balance. Decide this before you wire up the ledger, because it changes which accounts exist and who legally owns the float.
Takeaway
These three gates are design inputs, and the order matters. Settle fund-flow legality first, because it determines what accounts you are even allowed to build. Then fix your PCI architecture so card data never lands in your stack and you stay on the lightest assessment path. Then wire KYC and AML screening as hard, enforced gates in your onboarding state machine and your ledger.
Specific thresholds, exemptions, and network rules change, and they vary by state and by your exact fund flow. Confirm the current rules and get qualified legal review for your structure before you ship. The engineering lesson is constant: clear the compliance gates on the whiteboard, not in the audit.