A support agent asks a client to email a photo of their card to verify a deposit. That single request drags the firm's mailbox, its ticketing system, its backups and every laptop with a mail client into the cardholder data environment. Nothing was hacked and no rule about encryption was broken. Scope simply expanded, and with it the assessment burden and the liability if anything leaks.
PCI DSS, the Payment Card Industry Data Security Standard, is a contractual standard maintained by the card brands and enforced through acquirers rather than a law. For a broker or prop firm taking card deposits, the practical question is not "are we compliant" but "what is in scope", because the answer determines which self-assessment questionnaire applies and how much work follows.
Cardholder data and what counts
The standard distinguishes cardholder data from sensitive authentication data. Cardholder data is the primary account number, the cardholder name, the expiry date and the service code. Sensitive authentication data is the full magnetic stripe or chip equivalent, the CVV printed on the card, and the PIN or PIN block.
The hard rule: sensitive authentication data must never be stored after authorisation, not even encrypted. The CVV your checkout collected exists to be sent to the acquirer and then to disappear. Cardholder data may be stored if there is a business need, and if it is, it must be rendered unreadable, access must be restricted and logged, and retention must be defined and enforced.
Where firms trip is in the places nobody thinks of as storage. Support tickets with a full number pasted into a note. Call recordings where a client read the CVV aloud. Screenshots attached to a chargeback file. Server logs that captured a POST body during a debugging session. Each is a copy of card data in a system that was never designed to be assessed, and any of them is enough to make an encryption at rest policy irrelevant because the problem is location, not cipher.
Getting the card number out of your systems
Scope reduction is the whole strategy. There are two mainstream designs, and the difference between them decides which questionnaire you complete.
Full redirect or hosted payment page sends the client to the payment provider's own page or opens the provider's hosted checkout. Your systems never see the card at any point, and this is the lightest possible position. The cost is a break in the flow: the client leaves your branding, and conversion typically suffers on mobile.
Hosted fields, sometimes called an embedded iframe or elements, keep the client on your page while the card inputs themselves are served from the provider's domain inside iframes. Your JavaScript can style them but cannot read them. The provider returns a token, and your backend charges the token. Done correctly, the card number never enters your DOM, your logs or your database. Done incorrectly, for example by adding your own input that mirrors the number for validation, you have quietly moved into a much heavier assessment category.
The moment your own page collects the number in a field you control, even if you immediately forward it and store nothing, your entire web server, its dependencies and its deployment pipeline enter scope. Scripts loaded onto the payment page count too, which is why the standard now pays close attention to third-party script integrity on checkout pages.
Which questionnaire applies
| Setup | Card data path | Typical SAQ |
|---|---|---|
| Redirect to provider page | Never touches your systems | SAQ A |
| Provider-served iframe fields | Never touches your systems | SAQ A |
| Your form posts to provider | Passes through your page | SAQ A-EP |
| Your server receives the number | Enters your infrastructure | SAQ D |
| Telephone orders keyed by staff | Enters your voice and desktop estate | SAQ C-VT or D |
The jump from SAQ A to SAQ D is not incremental. It moves the firm from a short list of questions about outsourcing into a full control set covering network segmentation, vulnerability scanning, penetration testing, file integrity monitoring, key management and formal access control. For a firm of ten people, that is a project with a permanent operating cost. Almost nobody running a brokerage needs to be in that position, and the ones who end up there usually did so by accident.
Transaction volume determines the validation level and whether an external assessor is required rather than a self-assessment. That threshold is set by the card brands and applies per brand, and your acquirer will tell you which level they consider you. The payment provider integration you choose therefore has compliance consequences well beyond its pricing.
Tokens, refunds and recurring charges
A token is a reference held by the provider that maps to a stored card in their vault. Your systems store the token, the last four digits and the brand, which is enough to show a client which card they used and to charge it again. None of that is cardholder data in the sensitive sense, so it can live in your CRM.
This is what makes recurring billing and one-click redeposits possible without holding card numbers. It also means a token is provider-specific: switching payment providers does not move your tokens unless the two providers arrange a vault migration, which is a real project and a real lock-in factor when firms plan a multi-provider payment strategy.
Refunds should always be issued back to the original card through the token rather than by any other route. Refunding a card deposit to a bank account or a wallet is both a card scheme problem and an anti-money-laundering red flag, and it is one of the patterns compliance teams look for during source of funds checks.
The controls that matter beyond scope
Even at SAQ A, a set of obligations remains and they are the ones firms neglect. The provider must be on the list of validated service providers and you must monitor their compliance status annually. Scripts on the payment page need integrity control, because a compromised analytics tag on a checkout page has been the mechanism behind a long series of card skimming incidents. Staff need training so that nobody ever asks a client to send a card image, and the ticketing system should reject or mask anything that looks like a card number on the way in.
Access control is the other half. Administrative access to the payment console should be limited to named individuals with two-factor authentication, and every refund or manual capture should leave an audit entry tied to a person. That record is what protects the firm during a dispute, and it overlaps almost entirely with what an AML examiner will ask to see.
SINGUARD builds software for trading firms and integrates with payment providers rather than acting as one. Our position in every deployment is that the platform and CRM should be architected so the firm never holds a card number, which keeps our clients in the lightest assessment category available to them.
"Nobody sets out to store card numbers. They end up in a ticket, a call recording and a debug log, and then you are explaining to an assessor why your helpdesk is in scope."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- CVV, PIN and full track data must never be stored after authorisation, and cardholder data may only be stored with a defined business need and retention limit.
- Provider-hosted pages and provider-served iframe fields keep the card number out of your systems entirely and place a firm in the lightest questionnaire category.
- Collecting the number in a field you control pulls your web servers, dependencies and deployment pipeline into scope, and the jump to a full assessment is a permanent operating cost.
- Tokens are provider-specific, so switching payment providers requires a vault migration and is a genuine lock-in factor when planning payment redundancy.
Frequently Asked Questions
Does PCI DSS apply to a broker that only takes bank transfers?
Not for card data, since there is none. Firms that later add card deposits should design the integration for the lightest scope from the start rather than retrofitting it after the first assessment.
Can a CRM store the client's card number for repeat deposits?
It should not. Store the provider's token plus the last four digits and the brand, which supports repeat charges and client display without holding cardholder data in your systems.
What is the difference between SAQ A and SAQ A-EP?
SAQ A applies where card data never touches the merchant's systems, such as a full redirect or provider-served iframe fields. SAQ A-EP applies where the merchant's own page controls the form that posts the data, which brings the website itself into scope.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.