Tag: malaysia (Page 1 of 4)

PCI-DSS – Merchant EDC and Scoping

Many merchants we meet often tells us this: They are not in scope because they only do EDC (electronic data capture) – or payment terminal – transactions and these belong to the bank. Therefore, the bank has to ensure these are compliant and merchants do not need PCI-DSS since they do not store credit card.

Upon this, it’s the prevailing myth that storing credit card information is what PCI-DSS is all about, and as long as we avoid this, we don’t need to be PCI.

While non-storage of credit card does reduce scope SIGNIFICANTLY, it’s not the only thing PCI is harping about. It’s pretty clear in the standard itself:

PCI DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.

I don’t blame the merchants. They already have a hard enough time competing in a new digital landscape of virtual buyers and getting margins from their products – the last thing they need is a consultant coming in, brandishing some sort of standard called the PCi-DSS and the only thing that flashes through their minds is: How much is this sucker going to cost me, now ?

But it is what it is and we try to make our client’s (or in many cases, not even our clients, but anyone who calls us – and doesn’t even need to pay) life easier – and provide enough information for them to decide whether they need consultation, help or go it alone for PCI.

Yes – we technically consult them to potentially not consult with us.

But we believe in the long run, trust is something every consultants or advisors need to earn and it’s not something that comes with the territory. In fact, if I had a ringgit for every joke made about CON-SULTANS…we wouldn’t need to make any more new sales.

Anyway back to PCI. So the question to ask back the merchant is simply: “Great that you don’t store – but do you process card data?”

“No we don’t, the bank does it.”

“You don’t handle card data?”

“Handle? As in physically handle?”


“Of course (now somewhat flustered) – how do we get customer card if we don’t handle it?”

So in that sense – they answer their own question – if they are not there (handling the card), there is no transaction and no processing of card. Therefore, they are involved in the processing of card data. Does PCI apply? Yes, it does.

How does PCI apply?

Again, I am not going into the story of levels (how do be validated) vs controls (what to be validated) – already covered in previous posts on this, recently here .

But before our merchants get discouraged, most of their scope is very limited and in fact, I recommend them to try and go it alone.

Scenario 1

Their EDC connects directly to the bank through a dial up or cellular. No storage of card.O Only flow is to receive card, dip it, wave it and pass it back to the customer. That’s it.

Look at SAQ B. Last check, there are 41 questions. You don’t really have too much complexity in there, except to just ensure information security policy is there, physical security of the EDC is there etc. It’s not that difficult and really, most merchants should try to at least get these done.

Scenario 2

Their EDC connects to the bank via the merchant broadband.

This becomes trickier as this means the card data potentially passes through devices in the customer premise. This also includes when the branch locations sends credit card information back to the HQ and uses the HQ own internet set up to send to the acquirer. Another permutation here is that the acquirer would have their own equipment in the customer HQ where all branch data is consolidated to and sent.

The above scenario is more often found in very large Merchants.

In this case, the best bet we can go for is SAQ B-IP, with around 82 questions. Again, card data cannot be stored (full 16/15 PAN) or Sensitive Authentication data like CVV or track or PIN cannot be stored. In this case, PCI can still accept SAQ B-IP but most of the interim systems will be in scope for SAQ B-IP controls.

The trick here is really the SAQ B-IP requirement:

“The standalone IP-connected POI devices are not connected to any other systems within the merchant environment (this can be achieved via network segmentation to isolate POI devices from other systems);”

This is not as easy as it sounds as many environments still have their EDC all in a flat network as any other systems, and part of the requirement will need these EDCs to be properly segmented out to avoid pulling in the entire corporate into scope. This becomes complicated further if EDCs connect via wireless.

Another thing to be aware of is that you probably need a letter or confirmation from the acquirer that the entire card flow is encrypted end to end – meaning from the EDC all the way to acquirer environment, rendering the merchant environment as simply a transition point. Think of a road, being used by an armored truck that the merchant has no access to, as they do not have access to the encryption keys.

Other than that, depending on the number of segments you have – segmentation penetration testing is probably another headache you need to look at. However, this can be done via sampling, so consult with either the QSA or PCI expert for an idea of what an acceptable sampling is. Due to the risk being rather low, the challenge here is just to ensure that all setup is standardised across stores.

Your EDC shouldn’t be relying on your POS machine to send card data or process. The POS should only be passing transactional information and any information obtained from the EDC should be truncated PAN (if necessary) or only transaction information.

There you go.

With these, you can probably navigate through the initial headache of PCI for your merchant environment! Let us know at pcidss@pkfmalaysia.com if you have further questions! Since we sometimes consult you not to consult us, it would definitely be an interesting discussion!

PCI-DSS: Business Not As Usual

Have you heard the phrase Too Long, Didn’t Read? What if this applies to your PCI DSS compliance program, rephrased to “Too administrative, didn’t’ do?”.

We get this all the time in our meetings. Everyone mobilise for the big PCI project, everyone celebrates when they get certified and everyone suddenly gets collective amnesia and forgets about it. They forget there are daily requirements (like daily review of logs), weekly requirements (like FIM file comparisons), monthly (like critical patching), quarterly (ASV etc), half yearly (firewall reviews etc) and annual (testing etc). Yes, there are such requirements. We generally encourage our client to celebrate their success for first time certification but keeping in mind these obligations. Certain things you just can’t afford to miss out like your ASV scans and Internal VA scans.

PCI calls this Business As Usual (BAU). Being so long on the receiving end of these compliance requirements and now dishing it out in our advisory, I can safely say: PCI isn’t business as usual. In theory, yes, it should be, but theory and reality remains as far away as the possibility of Malaysia winning the next World Cup. A lot of our clients, after winning the PCI certification, find themselves completely overwhelmed with the so called Business As Usual theory that they wonder, whether after achieving PCI Business As Usual whether there will be any Business left to be usual about.

So what happens now that you are PCI compliant? When you are planning your PCI DSS compliance maintenance, you may want to setup a team to look into all the requirements, be it the technology, process and people. After you get your PCI DSS compliance, remember, the ‘maintenance’ clock starts. Yes. So if you take 2 months to celebrate your victory over this dastardly villain called PCI, you technically have one month left to do your Internal Scans and ASV scans. So don’t forget about what you need to do. Your PCI team needn’t be dedicated personnel (Very few companies can afford that), but there should be a lead person, relatively not bogged down by day to day operation works, and ideally independent from the operations as well. If you have a info sec team, it would be good, else a technical project manager to lead and the responsibilities to maintain, to go back to the process or system owners.

True, even before PCI arrives, you are probably already bogged down by other compliance requirements on top of your normal day to day. ISMS, customer audits, regulatory audits and assessments, internal audit, and now PCI. It’s like eating pancakes after pancakes except these are horrible tasting pancakes.  You might forget some of the administrative tasks that need to be maintained as part of your PCI DSS compliance process and we have had customers scrambling to complete their quarterly scans after missing them. Eventually, after a period of time, all these tasks will pile up on your plate and you are left with the prospect of being unable to be recertified. Your PCI DSS compliance will be at risk of becoming non-compliant and void and really, it’s not something the board will be too happy about, after taking 3 months of budget to celebrate the victory earlier. It’s like winning the English Premier League one season and getting relegated the next. The emotions are too much. We may think these maintenance tasks are petty but it is an important component in your PCI DSS compliance ecosystem.

Here are some insights to some examples of these administrative tasks that might be missed:

Changes on firewall/switch/router rules or configuration– it is highly critical that before a change is done, proper testing, approval and documentation are carried out. As these devices are critical components in the network infrastructure, any misconfiguration may result in security issues or in our observation, even bring down the whole network and have people scrambling over the weekend unnecessarily. Proper testing and approval process are any case required before changes can be made and this must be documented. Documentation provides an audit trail of changes and why these changes are required. So, don’t forget to document this process. Or risk the weekend being messed up.

Patching – There is this perception that if I’ve setup my systems to perform patching automatically, everything is well. Wrong! You need to review the patches and ensure that it is safe to be deployed and it will not like, I don’t know – crash your production systems? Next is to make sure the patching applied is being documented so that you have a history of updates on your system. A configuration information (CI) system can do that, or you can ensure you run your inventory checks regularly, as Windows would keep track of these applied patches. If the system is being patched up manually, you need to have the procedure of checking for updates on a regular basis. Make it a habit to check if your system is running with the latest patches regardless if the patching is automatic or manual by making it as a checking activity in your periodic task list. Remember, PCI would require a one month critical patch deadline and three months for non critical security patches.

Anti-malware – anti-malware will normally update automatically and periodically and we will assume that it will run as what it is being configured to do. As such we will not bother to check unless something bad occurs (which almost always does). As part of your administrative task, you should make it as a daily task to check the anti-malware system status, malware detected and the resolution of it and put this task in your checklist.

Logging and Monitoring – PCI DSS requirement 10.6.1 requires review of security events at least on daily basis. Most people stare blankly at me as if I’ve just told them elephants do wear tutus and can fly. Then they realise that I am not joking, they shake their head and invariably say (in variable tones, depending on how incredulous or stupefied they are): “WHAT?! DAILY?!?” .

Well, yes, in a way, although PCI in its supplementary document Effective-Daily-Log-Monitoring-Guidance.pdf, they have provided this little leeway for your ease:

“A reasonable timeline must be defined to allow less capable organizations to perform security log reviews while still enabling the organization to detect malicious or anomalous activity before it can likely escalate. In the case of Requirement 10.6.1, PCI DSS has determined that timeline to be a maximum of 24 hours or one calendar day.”

So when we refer to ‘daily”, it is with this definition in mind. Still a difficult one, but hey, OK.  In our advisory works, we have seen that clients often miss out the daily review and alert they receive (usually through email). It could be a SIEM (Security Information and Event Monitoring) system is deployed and configured to identify a threat and sends out an email to the person in charge. Instead of monitoring this email that might be a critical security issue, it is not reviewed. Not reviewing security alerts is a risk that may have adverse effect for obvious reason. In a recent retailer breach, for many months hackers were siphoning information from their POS systems to a spool server and removing that data file to an external system. If reviewed properly, such an abnormal data flow might have been spotted.

So, these are a few of the admin tasks. There are a lot more. Moving forward, be diligent, make it a habit to not miss any of these out and incorporate these administrative tasks as part of your daily routine tasks. Other tasks include ensuring quarterly testing such as ASV, annual penetration testing, etc as described in requirement 11 are carried out properly and given enough time to perform. Don’t expect your team or vendor to do a pentest on 50 systems and tell them to complete it by tomorrow. Failure to observe PCI timelines may result in you losing your compliance.

Don’t get relegated after winning the league!

Contact us at pcidss@pkfmalaysia.com for further queries on PCI-DSS and we will set up a meeting with you as soon as you are available.


So, it has been a while since we’ve updated on the ongoing PCI-DSS program from IATA. Just a brief recap then: Airlines have demanded that IATA support their own internal compliance project by making the BSP (Billing Settlement Plan) card sales channel PCI DSS compliant. This is why IATA Accredited Travel Agents now need to become PCI DSS compliant by 1st March 2018. Yes, that’s roughly 6 weeks ahead of this writing. And no, it doesn’t seem like there might be any extension towards this compliance from IATA. However, there are some pretty big news headed your way on this compliance, as we are in touch with IATA over the last couple of months and also assisting many travel agencies to get PCI-DSS sorted out in their payment channels.

However, for this article, we will focus on the brand new FAQs that just came out a few days ago (18 Jan 2018)! You can find the updated FAQs here at http://www.iata.org/services/finance/Documents/pci-dss-faqs.pdf, and we are going to look through a few changes.

FAQ #3

What if I do not have an acquirer?

Old FAQ: We suggest that you contact the credit card branch that you are working with.

New FAQ: In that case, you are solely accountable for the PCI DSS compliance of the BSP card transactions you are making on account of the airline whose ticket you are selling. We suggest you contact your GDS provider who can provide some guidance, and then review through which of your systems card details transit or are stored. Starting from this you will know which of your systems
must undergo a PCI DSS evaluation.

Our opinion: The first FAQ was of course, not exactly extremely helpful, since most credit card branch does not give two hoots about travel agencies banging down their doors in search of their response. The new FAQ is basically saying, well – you just need to figure out yourself then, but you can ask the GDS guys if you wish. We have. The GDS guys are very important in this factor, because they first need to be PCI compliant. Sabre, Amadeus and I think Galileo Travelport is. Secondly, they can give some guidance on how agencies can approach PCI based on the client software that is installed on the agency side.

What do we mean by this? Because for agencies not storing credit card, they can possibly be eligible for shorter SAQ (Self Assessment Questionnaires) for PCI. An SAQ D has 340+ questions. An SAQ A has only 20+. If an agency uses the GDS for credit card passthrough transactions (i.e the credit card form of payment), and not store credit card information in the back office or any electronic form (email, skype, excel etc), they might qualify for shorter SAQs. The question is which?

Some advisors claim the SAQ C is correct due to the fact that the GDS is a payment system. The reasoning is that this is no different from integrated POS systems like Micros. In Malaysia, we have hundreds of different vendors in POS solutions for retailers, F&B franchisees etc. But is the GDS really like an integrated POS solution? SAQ C has around 160 questions. The amount of time you will spend on this is probably the same amount of time taken to watch two seasons of the Game of Thrones. Or three, depending on whether you binge watch or not.

Some advisors veer to the other extreme, claiming that the GDS client is simply a browser system that is redirecting the entire card data processing work to the GDS provider, so they are eligible for A. 22 questions. Maybe an episode of Seinfeld. But A is generally for a web browser based site with absolutely zero handling of credit card on their end, not just systematic, but also manual. The only way this works for travel agency is that they outsource an entire call center to handle their MOTO business and do not accept walk-in customers. I don’t think that’s happening. Most feedback I get from livid agencies about PCI-DSS is that they are struggling too much on thin margins. So, no, SAQ A is entirely too liberal.

SAQ C-VT has a seemingly better balance to it, as discussed in our previous articles Part 1 and Part 2.

We even sent out queries to two GDS (their names pending once I get their agreement to publish) and their responses were these

Amadeus: (When Queried if SAQ C-VT is correct to be filled, and if the Amadeus Selling Platform can be eligible for VT): Basically, if the payment is done via Amadeus and entered manually from a personal computer directly into the GDS – you have a right form for Amadeus agents and tick it off with confidence. 

I believe your original question was ‘If Amadeus is considered virtual payment terminal?’

Our answer is Yes.

Sabre: (When asked if their client acts as a VT, defined by PCI as having “Internet-based access to an acquirer, processor or third-party service provider website to authorize payment card transactions.”) Yes, Sabre Red Workspace client requires an internet connection to authenticate and then it requires connections (dedicated or ISP with VPN) to connect to Sabre and no, it does not do batch processing. You may consider SRW is a virtual terminal and guiding your travel agency clients to achieve their goal.

Travelport (Galileo):  (When asked if their client acts as a VT, defined by PCI as having “Internet-based access to an acquirer, processor or third-party service provider website to authorize payment card transactions.”)

Yes. Galileo client does not store credit card information on the client software and client software requires internet connectivity, and cannot do batch transactions.

Based on these ‘guidance’ from GDS which IATA seem to defer to, SAQ C-VT is a likely possibility, as long as all the other eligibility are met. The GDS all claims they are virtual terminals, but that itself (while an important eligibility) isn’t the ONLY eligibility for SAQ C-VT, so you need to ensure the others are met before claiming SAQ C-VT is correct or your business.

Whew. That was a long one. Now back to our FAQs.

FAQ #9 : As a travel professional issuing and selling airline tickets, am I considered a merchant?

This is removed and rightly so. Though the previous response was right: “All the airline transactions processed through a GDS (Global Distribution System) and IATA BSP, the airline itself is considered as the merchant, not the travel agent.”

It only serves to confuse an already confused population further. It’s better they don’t explain this, because some agencies interpret this as IATA saying they are not ‘merchants’ so they need to be ‘service providers’. WHAT! So, yeah, we can explain in another article but this is better left out.

FAQ #22: We already have a PCI DSS Compliant certificate issued by a third party.
Is this enough to cover our BSP or do we need to complete more forms?

Not an addition or whatever, but I still wish that they would change this because the answer doesn’t match the question. The answer is lifted directly out of the PCI-DSS Top 10 Myths addressing the need for a QSA to be involved in the process. The answer is , it is recommended, but NO, for Level 3 and 4 merchants, there is no requirement to get a QSA involved.

Finally, a bonus opinion here.

Many agencies are still faltering in their PCI-DSS compliance. Some equate that just because they are level 3 and 4, they do not need to do ASV scans or penetration testing. Likewise, there are those who *might* theoretically (we don’t know any) qualify for level 1 or level 2 based on their volume, automatically assume they need to do ASV scans and do pentest for everything in scope.


Your merchant level DOES NOT dictate whether you need to conduct PCI scans or not. We need this to be clear. Because the table published in the FAQ from IATA for FAQ#13 isn’t clear (not their fault, this was lifted from the Mastercard site) – the column “Validated By” states ‘merchant’ and below “Approved Scanning vendor” for level 2 and below. This immediately presupposes that an ASV must be involved. This is incorrect.

Your level (determined by your card transaction volume) determines your VALIDATION TYPE. Validation type there are 3: QSA Certified/Validated; Validated SAQ by QSA/ISA and SELF SIGNED SAQ by MERCHANT OFFICER. That’s it. Your level doesn’t determine how you go through PCI, it determines how it is validated. And it’s not set in stone. Your acquirer can bypass these guidelines and decide that even if you only do ONE transaction a year, you still must go through level 1 compliance (audited by QSA). This is actually quite common!

So what actually determines what on earth you actually do in PCI-DSS?

Well, it’s your business. Or, for Level 2 merchants and below, your type of SAQ. You see, it’s your business that determines your SAQ type, it’s your SAQ that determines what you need to do, and based on what you have done, it will be validated in either of the 3 ways we’ve described above. That’s the harmony of PCI. That’s the zen. The yin and yang. The balance in the Force.

So, for instance, if you are doing SAQ A, SAQ B or SAQ C-VT, please point out to us the fact that you are REQUIRED to do ASV scans on all your internet address (some are told, even their dynamically allocated broadband IP must be scanned by ASV).

None. Magically, SAQ A, SAQ B and SAQ C-VT DOES NOT HAVE ANY requirement for ASV or penetration testing. For us who can provide these services, of course it kind of sucks since now those going through these SAQs don’t need our services anymore. But we rather tell them straight the correct way and sacrifice that part of our business than to let them know wrongly and give consultants a bad name. So what SAQ you are doing will determine whether you need to get something scanned or not.

Now, of course, do not be tempted to fit your business into the easiest SAQ for the sake of it (see the example of travel agencies with GDS doing SAQ A) – there are huge eligibility requirements for these 3 SAQs and not many agencies can meet it. If you practice accepting cards through email, or photos on Whatsapp for your credit card; or store in back office for later processing, or have Enhanced Data Services from Visa/Mastercard or a thousand other ways you can be receiving credit card, you likely need to fit back into the dreaded SAQ D. But what we are saying is that if you ARE eligible for A, B or C-VT, then those will determine whether you need to do any testing or not.

It is our opinion that testing and scans should be done regardless for security sake, not so much for compliance but the choice is yours. You need to make that decision for your own business. Because that’s what heroes do.

If you have further queries on PCI-DSS or just how we are currently helping our clients get through PCI, drop us an email at avantedge@pkfmalaysia.com. We will respond ASAP!

PCI-DSS v3.2 for ePetrol Services Sdn Bhd

Congratulations to ePetrol Services Sdn Bhd for being certified PCI-DSS v3.2 Level 1!

ePetrol is a secure and reliable payment switch and service provider that offers a variety of payment solutions to a broad spectrum of industries encompassing oil and gas, finance, healthcare, retail, e-Government and telecommunications.

Founded in 2007, ePetrol – a subsidiary of Dialog Group Berhad – is a MSC status company which conceptualised and pioneered an innovative payment system which uses the Malaysian National ID Card (MyKad) as the payment instrument for purchases of goods and services. Their MyKad solution is also designed for welfare distribution and subsidy management.

Besides payment, ePetrol offers variety of IT solutions such as Loyalty Solution, Scheme and Entitlement Solution and Enterprise Management Solution to meet the client’s needs.

PKF and ePetrol actually had started the PCI journey together earlier, however due to the move from their old office to the current Dialog Tower, we then rebooted the process. We are happy to be part of the journey of PCI and the highs and lows we have had with the team. It has truly been a fulfilling experience in the project and we are looking forward to serving ePetrol for years to come.


IATA PCI-DSS: Who is doing what?


We have been receiving a ton of emails and inquiries lately ever since we started marketing our services for PCI-DSS to travel agencies. It has to be noted that some of these travel agencies were our clients to begin with. PKF has a very large set of customers because we do the entire end to end corporate services. We are not just one technology advisory firm. We have tax advisory, business advisory, internal audit, external audit, outsourced, accounting, corporate finance, forensics accounting etc. So over the course of 20+ years we have amassed a ton of clients and many of them are travel agencies, whether in technology group or in others. This is where our main queries stem from. Existing travel agencies are querying us and in turn they are letting others know about us, so much so that we are now compiling an FAQ to address all questions being thrown at us on PCI-DSS.

One common question we get asked is: WHO is initiating this PCI-DSS?? We even get accused of being the ones initiating this PCI-DSS on them and planting a deadline of March 2018 for them.

So let’s get the story here straight. For this, it is necessary to go from the beginning to the brief history of PCI.

a)  PCI-DSS began its life in 2004 but only in 2006, PCI Council was formed to govern this standard. The council is now made out of card brands Mastercard, Visa, Amex, JCB and Discover/Diners. The purpose was to ensure there was a standard way that merchants/service providers can secure their credit card interacting systems to, instead of to each individual card brand’s compliance. It’s a good thing. Basically the whole idea is to ensure the whole ecosystem where credit/debit card is used/processed/stored/transmitted is secured.

b) IATA’s story probably began back in 2015 when, according to GDS Amadeus, VISA Europe issued a deadline to acquiring banks using its network that all airline merchants should be PCI-DSS compliant by 31 December 2017. So the airlines got into a huff and took a look at their processes, which is like any other merchant – they have their acquiring bank to do the authorisation, clearing and settlement. So far ok.

c) However, the airlines had one problem: Indirect distribution channel. This is where airline tickets are distributed via travel agents, either through walkin, MOTO or internet. Travel agents use a GLOBAL DISTRIBUTION SYSTEM (GDS) that link to airlines to check for ticket and also to financial institutions for authorisation. And these finally link to IATA. Why? IATA has the Bank Settlement Plan (BSP) to – yup you got it – facilitate the clearing and settlement. BSP allows many travel agents to connect to many airlines, allowing a one stop shop to ensure everyone gets what they want, instead of travel agents separately dealing with airlines and vice versa. It’s orderly and it helps the industry.

d) However, the BSP, due to its connectivity to the Airlines now needs to ensure its downstream connecting parties are also PCI-DSS. Cue, travel agents and this is where IATA tells the travel agents, look, get your act together because the airlines need to be certified, so we need to be compliant, so you need to be compliant.

So in conclusion, it is IATA initiating it to the agencies – because there is an upstream push for them to be compliant. It’s common as well – many times payment gateways are asked to be compliant by their bank – we hardly see any entity embarking on PCI-DSS just because they feel that it’s the best thing to do for them. But the overall initiator of PCI still remains the card brands – whether it is VISA, Mastercard or Amex etc.

Now the question here is this – because IATA is considered a processor (with their BSP), they are enforcing a deadline of March 2018. At the same time, they also need to provide a way for agencies to submit the compliance document.

It’s a bit confusing here, because Agencies are also merchants in their own sense. They also have their own channels to collect payments, and some payments are made directly to their merchant account, and they settle with IATA through cheque/cash/bank in etc, not via card. Everytime a card is entered in the BSP, the agency is acting in behalf of the airlines using the airlines merchant ID. Everytime a card is used in the merchant’s own environment such as POS, EDC or Internet, the agent is the merchant, and they do authorisation, settlement etc through their own bank. IATA/BSP is not involved in the credit card flow in this case.

However, because IATA is requesting PCI to be adopted by agencies, agencies also need to look into their other channels that do not involve IATA! So imagine, an agency does their SAQ C/C-VT and sends it over to IATA, but to cover their EDC or terminal business, they do an SAQ B – who on earth do they send this over to? Well they send it over to their own acquiring bank. Their bank asks: Hey, what the heck is this? Well, it’s our PCI Compliant SAQ/AoC, Mr Bank. And Mr Bank is happy but somewhat confused and asks: Why are you doing it anyway? I didn’t ask you to do it yet because you only do 1 – 2 transactions with us. (Please note, even if it’s 1 – 2 transactions, you are still considered a Level 4 merchant, but most banks are ensuring their large volume merchants are compliant first). So therefore, agencies have two upstream processors to send their PCI documents to – IATA (for IATA channel) and their own bank, for others.

In the next post, we will explore on the validation requirements and why its so important to know what validation requirements apply to you and how. Do drop us a note at pcidss@pkfmalaysia.com. We are having a bunch of queries, but we will answer you ASAP.

« Older posts

© 2024 PKF AvantEdge

Up ↑