Integrated risk management environment
The end to end risk management during the implementation and post EMV including the things we need to consider and how we can move to mitigate the risk of payment systems.
Fraud trends of EMV and post EMV
There are fraud trends during the implementation of EMV and post EMV, and you need to consider all the necessary measures that need to be deployed to address them and,
How you can begin to provide a managed risk environment for the future to safeguard your profits, reputation and customer service levels.
The primary strength, and one can argue the existence of EMV, is that it offers significantly enhanced security and risk management techniques over magnetic stripe.
However, it is not invulnerable and it would be wishful thinking to assume that fraudsters will give up this lucrative industry and try their hands at other professions due to the introduction of EMV.
So, what could the possible fraud trends be during the implementation of EMV and post EMV?
EMV migration an opportunity for fraudsters?
There is little doubt that during the migration to EMV, there will be ample opportunities for fraudsters.
Some of you in the risk management industry have probably been hearing for few years now how chip cards will replace magnetic stripe cards.
However, this has not yet fully happened. In all probability, its feasible to assume that chip and magnetic stripe cards will co-exist for at least another 10 years.
We will probably start reaching critical mass in terms of EMV cards and terminals in 2015 at the very earliest - of course that is only in those regions that have embraced EMV.
Currently, the European region, some countries in Asia Pacific and Canada have firm plans to move to EMV.
However, there is a huge mass of land called the United States of America which currently started in 2015 making plans for EMV.
There is a huge probability that if there were a few emerging countries in Central Africa, a few unknown small islands in the pacific which were not EMV compliant, most issuers would not hesitate to remove the magnetic stripe from their cards.
However, with the economic importance of the USA and with your customers regularly visiting the USA no one dare currently remove the magnetic stripe from their EMV cards!
There is some belief in the risk management industry that as most regions in the world begin to embrace EMV, this may cause some tension in the USA to move also.
The opportunities this offers to the fraudsters could be as follows:
- Huge deployment of cards and terminals
- Inexperience of cardholders and merchants
- Inexperience of customer services
- Readiness of risk management systems and procedures for change
- Stripe and chip co-exist for at least few years
As the various deadlines for EMV approach, there will be a huge deployment of EMV cards and terminals.
In the EMV world, the only way to really compromise cards is either to get hold of the card and the PIN or to get hold of the master keys.
Whether the cards are posted or picked up from the branch, the fraudsters will be well aware of this and will actively target those cards.
As a huge number of EMV capable terminals will be deployed - they should be quite accessible and easy to get hold of.
The fraudsters may well get their hands on these terminals to investigate how they work in order to try and compromise them.
They may well begin to deliver and install such terminals - it is not beyond the realms of possibility that they could tamper with these terminals before they are actually deployed.
Remember, that it will take just one single person in the chain in order to introduce compromise.
One area that fraudsters have continually surprised us (risk management companies) is with their ingenuity with deployment of technology.
You may have heard of ATM scams whereby a a card reader transmits the magnetic stripe contents to a nearby device using a GSM transmitter and with a remote camera capturing the PIN.
If they can intercept the point-of-sevices POS terminal, devices like this can be planted, alternatively the chip reader could also be damaged forcing the card to fallback to magnetic stripe.
The inexperience of cardholders and merchants with EMV chip cards is also an opportunity for fraudsters.
In the United Kingdom UK, chip and PIN is a totally new concept - for Banks, their customers and merchants.
Consider this real life example - Whilst buying petrol in the UK, it is normal for the cashier to ask for your mileage and maybe some other information to be noted onto the receipt.
A colleague recently told me how his nephew was recently asked for the PIN for their chip card whilst buying petrol in the UK.
Whilst his nephew was savvy enough to spot that this is suspicious, there are many other unsuspecting cardholders who would probably have given their PIN without thinking twice.
The cashier may well have asked this innocently due to their lack of knowledge about chip and PIN.
PIN at POS is a new concept in the UK and will take a while for all parties to get used to.
Similarly, the inexperience of merchants can also be taken advantage of.
There was a good example recently in a supermarket in the UK - it transpired that at one checkout desk all transactions with EMV cards were falling back to magnetic stripe.
After intensive investigation it transpired that the supermarket had hired a new girl to work at the weekend - she simply did not know how to use the chip reader as she had not been trained adequately.
We have all heard of account takeover, whereby the fraudster takes on a genuine customer's identity.
So, with the possible interception of EMV cards and the associated customer details before they reach the genuine customer, the fraudster may well be contacting customer services reps of the Bank to change their details.
The inexperience of Customer Service Reps in spotting this kind of fraud could make it difficult for them to spot the genuine cardholder.
We may all be so occupied thinking about the deployment of EMV, but we also need to consider the readiness of the risk management systems.
How will our fraud investigation processes need to change? How will we look for these new trends?
How will we manage our cards, terminals and general EMV infrastructure. This area requires serious consideration.
Risk Management Personalisation
Where are your keys managed? - Enhanced key management
Where is your card and chip data? - Essential to dynamic risk management
How do you manage mass replacement? Which cards are compromised?
How do you manage cards and application life-cycle?
EMV is a quantum leap in terms of both the number of keys to be deployed, key length, key expiry, etc. The only way to truly compromise an EMV card is to have the Issuer Master Keys.
In view of this, it is imperative that you deploy enhanced key management and your security department need to consider the potential for compromise should you decide to outsource your keys.
This means that any third party needs to have robust procedures and to run constant monitoring against insider compromise. Equally important is the need to have access to your card and chip data.
To move to the enhanced risk management environment, it is fundamental that you can easily interrogate what is on the card, what the current settings are, issue scripts to change parameters, track the life-cycle of changes and provide a comprehensive audit trail of the various parameter updates.
In the event that your keys do get compromised, or perhaps you are experiencing unusual SDA (Static Data Authentication) failure because your key(s) has expired - would you know which cards were impacted?
One of our customers experienced such a problem. They had outsourced risk management personalisation to their Card supplier who omitted to tell them that their keys had expired.
Their Scheme noticed that they had a problem, because they had not implemented the type of risk management environment.
They had no way of knowing which cards were impacted and ending up with a Mass re-issuance nightmare. Expensive; bad for customer, bad for image, bad for bank.
In migrating your cards always understand where you are on the EMV stepladder and understand what is required to get to the next step.
Without a facility to manage the cards and their application life-cycle you could find yourself in a difficult situation!
Chip and Stripe
With chip and stripe, fraudster will:
- Disable chip and force fallback
- Intercept mail
- Opportunity to damage chip and return to post
- Harder to track fraudulent fallback
- Stolen cards
- Damage chip
- Cross-border usage
- Compromise Terminals
With the co-existence of chip and magnetic stripe. Well lets now look at some of the possibilities for the fraudster here.
If the fraudster can get their hands on a card, they can simply damage the chip thereby forcing the card to fallback to magnetic stripe. So, all the extra security features of the chip are suddenly redundant!
If cards do get intercepted before they get to the cardholder, the fraudster has numerous choices of what to do.
They could simply steal the card, or a smarter move may be take a copy of the magnetic stripe to create a counterfeit, damage the chip and put it back in the envelope to be delivered to the genuine cardholder.
There are now two cards out there both using the magnetic stripe - it becomes a lot harder to track the fraudulent card!
Sith stolen cards, the chip could be damaged forcing the card to fallback to mag stripe, or it could be used cross border where for example EMV may not be deployed.
A few years ago, Bahrain is experiencing skimmed UK cards being used fraudulently and I am sure that Dubai must be given the extensive tourist throughput.
In a few years ahead of the EMV liability shift in the EU, skimmed UK and French cards were being extensively used in Spain.
So, the issuers were liable for all that fraud. The Spanish acquirers realised that come a year later, they would be liable for all subsequent fraud, so they soon saw the benefit in becoming EMV enabled!
Chip readers in POS terminals can be targeted, therefore forcing a chip card to fallback to mag stripe.
This could also be done after deployment and involve dis-honest staff targeted or placed into merchants.
Chip and stripe should be able to detect:
- Fallback - Need to Determine Why
- EMV-Term-Cap, Last-EMV-Stat, Pt-Srvc-Entry-Mode
- Chip Data Changed
- Chip Damaged
- Intentionally or Accidentally?
- Terminal Problem
- Compromised or Genuine Card Reader Failure?
If we have detected a fallback from analysing the EMV data, you need determine why. The listed EMV fields are some that you would be analysing to determine a fallback.
There could be many reasons for a fallback, such as the chip data may have been changed, the chip may have been damaged or there was a problem with the terminal.
If the chip is damaged or there is a terminal problem, how can we determine if this is intentionally or accidental?
We need to detect classical changes in behaviour by looking at the customers profile, and analysing other information such as:
At what type of merchants are these fallback transactions being performed? How many fallbacks am I seeing?
Are these coming from a known point of compromise? What transactions precede the fallback? Neural networks are very good at detecting changes in behaviour for a customer.
Card not present
With card not present, we're talking:
- MOTO and Internet already showing increase
- Few computers have chip readers
- Schemes have introduced Securecode and VbV
- MasterCard have introduced a one-time password device
- MCAP or VISA DPA
Card Not Present (CNP) is not a new phenomena and is growing rapidly. Figures from the International interchanges indicate that anything upto 35% of all CNP transactions are chargedback.
In the UK a few years back, counterfeit and skimming fraud declined, however the rise in CNP and account takeover fraud caused overall fraud levels to rise.
This is also an obvious target for EMV cards - no card is required therefore enhanced security features on the chip are bypassed.
There are few PC's today with chip readers - maybe we need to get to a stage where a chip reader is standard equipment on every PC sold - just as a CD or DVD reader is.
Having said that, some people may be concerned at connecting smart card readers to their PC's as these could be compromised also!
This may be more viable if the correct level of security is deployed on and around the card readers.
The card schemes have tried to introduce enhanced security with programs like Mastercard SECURECODE and Verified by Visa.
However these are complicated to implement in as much as you have to register the acquirer, merchant and card.
These environments are sometimes complex to establish so the take-up has not been as great as hoped. Mastercard have recently introduced the MCAP Solution.
The card is inserted into a small device or widget, this will challenge the card and generate a number.
This number is then entered into the website and authenticated by the acquirer, thus proving the authentication of the card.
However it will take some time before the take up of this is sufficient to counter CNP fraud. It is this "token based" type of security feature that is most likely to tackle CNP fraud.
For Card not present type fraud, check:
- MCAP Device
- Given to customer, but not used. Why?
- EMV data in CNP transaction
- Cryptogram (ARQC), Application Transaction Counter (ATC)
- Check ARQC-Verify flag in EMV Data
- Customer behaviour & trends
- Rules and Neural
With Card Not Present type fraud, you can check whether this customer has been issued with a CAP Device.
If so, why was it not used? We can then check the behaviour for this customer - does this customer normally use the CAP device for CNP transactions? Does this customer usually perform CNP transactions?
If a CAP device is used, the only EMV data in the transaction will be the cryptogram that the device has generated and the application transaction counter.
We can check the ARQC-Verify flag to determine if the cryptogram was valid, and the authorisation process can also verify the ATC.
We still need to analyse the customer's behaviour by using rules and or neural technology.
The EMV fields are good indicators of possible fraud, even in the CNP environment where few are provided, they are very valuable pieces of information.
With identity theft, check:
- Fraudulent applications, account take-over, additional or replacement card
- Card and identification theft
- Ease of access to personal information
- Pressure on bank employees
- Monitor for internal fraud, pretext calling, etc.
- Over the last couple of years or so, the area of identity theft has been growing rapidly.
Fraudsters have quickly worked out that committing fraud is a lot easier when you can convince the bank or another party that you are the genuine customer.
You suddenly have access to all the accounts and can basically do as you wish with them.
One of the main reasons for the increase is that personal information is easily accessible.
I am sure I am not the only person in this country that has thrown away paid bills, letters and bank statements before actually destroying them.
The fraudster only has to go through your rubbish to work out who you are and other important information about you like your date of birth, account numbers and so on.
Then there are the phishing scams whereby personal details are being captured fraudulently on the internet.
Once the fraudster can assume your identity, they are free to take out loans and other products as well as eventually clearing out your accounts!
Your staff obviously have access to a lot of sensitive information about your customers. They are obvious targets for criminals - they can put pressure on your staff to provide customer information.
You need to ensure that your staff understand the types of questions and queries been asked.
For example, someone may call to ask why their re-newed card has not arrived and could you tell them which address you sent it to, as they have had a few letters missing recently.
Equally important is monitoring for internal fraud and monitoring for unusual activity across the customer's accounts
With account takeover or identity theft, check:
- EMV Fields
- New-Card Flag (TVR)
- Application-Not-Yet-Eff Flag (TVR)
- Pin-Try-Limit Flag, Online and Offline (TVR and CVR)
- Changes in demographic info
- Enterprise-wide view
- Cheque fraud
With regards to account takeover and id theft, any products issued should utilise the EMV card and application activation fields - the new-card and application-not-yet-effective flag.
On the first usage of the card, the risk management system should be configured to perform more vigorous testing to ensure the customer is genuine.
The PIN-Try-Limit flags - both offline and online should be analysed as they can provide vital clues.
For example, the online PIN-Try-Limit flag may look fine, however the offline PIN-Try-Limit flag may show that the limit has been exceeded.
This could indicate that a fraudster may have tried to work out the PIN in an offline environment - especially if your offline PIN-Try Limit is quite high - like 10.
Or it can indicate that a shoulder surfer may have seen the first 3 digits of the PIN, but needs to work out the last one.
The Risk Management system needs to be able to detect any changes in the customer's demographic information - such as a change in address.
If there has been a change in address recently, then more stringent analysis should be performed.
Imagine a Risk Management system that takes an enterprise wide or customer centric point of view.
Instead of analysing one product such as a credit card, if it analysed all the customer's products.
Such as all card products, current and savings accounts, and other financial products, any change in behaviour in any of these can be quickly determined.
With cheque fraud, it is:
- Easier than compromising EMV card
- Quality of printing facilities
- Still widely used in some geos
- Lack of risk management in area
- Need for Enterprise Risk Management
Still viable until magnetic stripe goes:
- PIN compromise via electronic, photographic techniques in addition to shoulder surfing
- Speed of global deployment
- Range of deployment
- Easier than trying to counterfeit the chip card
Whilst magnetic stripe cards exist, counterfeiting a EMV chip card is still viable. You simply utilise the card forcing it to fallback to mag stripe, or you use it in those regions where EMV is not deployed.
We must of all heard of the sophisticated techniques being used not just to counterfeit the card, but to capture the PIN also. The mass rollout of cards eases access to those cards.
We will see an increase in activities whereby the fraudsters will try and get hold of the EMV chip card and the PIN - like the lebanese loop type activities.
Reports from the UK already show a sharp increase in lebanese loop - in an EMW world, the only way to truly compromise cards is either to get hold of the card and the PIN, or get hold of the master keys used for encryption.
A primary area of card compromise is within the family. The only way to recognise this would be change of behavioural pattern.
- EMV Fields:
- ICC-Data-Missing - Terminal verification results (TVR)
- Offline Static Data Authentication Failed (TVR)
- Card Verification Value (CVV), Card Verification Value for Integrated Circuit Cards (iCVV) the same?
- Service Code Re-Writing
- Application Transaction Counter (ATC) differences?
The ICC-Data Missing and Offline Static Data Authentication Failed flags should be analysed.
These can indicate that bad data may have been copied onto the chip.
Its easier to copy the EMV risk parameters, but harder to copy the offline PIN and keys as it is held in a secure part of the card.
Other checks can include checking the CVV and iCVV, is the service code valid and differences in the ATC.
Challenges of EMV Smartcard Adoption in the USA
Today's challenge for EMV and risk management of payment systems. It's not all positive and roses, however: Security issues and problems with EMV smartcard adoption in the United States of America USA.
- SDA Compromise
- Service Code Re-Writing
- Early Option - Magnetic Stripe on a Chip
Whilst Static Data Authentication (SDA) provides a vastly more secure environment than Magnetic Stripe, by its very nature SDA uses static data elements and it is not unreasonable to assume that sooner or later the criminal may work out what these are.
Having said that, to date SDA has only been compromised in laboratory conditions using a machine with huge processing power - it also took several days.
By comparison to magnetic stripe compromise it does not provide a very good ROI (return on Investment) for the criminal.
However, we can be sure that they will be working on ways of making it feasible as the world migrates and the cost of computing/computer power, etc. reduces.
We need the systems in place to detect systemic attack and the ability to react accordingly.
Another possible technique fraudsters can deploy whilst counterfeiting cards can include Service Code rewriting to change the information in the magnetic stripe to indicate that the card is a magnetic Stripe card only.
When read by an EMV enabled terminal, its service code will indicate that it's a magnetic Stripe card will bypass the all the extra security features of EMV. The Enhanced authorisation process should pick this up.
The iCVV refers to the CVV in the chip. This should be different to the CVV on the magnetic Stripe.
If a fraudster tries to create a magnetic Stripe image on a chip they will probably use the CVV in the magnetic Stripe - you can easily determine that the iCVV is incorrect during the authorisation process.
The schemes have allowed "Early Option" in some GEOs. Be aware that this is a very limited application of EMV.
It is effectively the magnetic stripe on a chip and provides for few of the comprehensive fraud and risk management capabilities.
None of the key EMV data elements are passed through to the Issuer for them to analyse. It also represents lost opportunity going forward when one considers some of the potential.
EMV card Controls
We have just presented the possible fraud trends during the migration to EMV and post EMV. Now lets look at what we can do about it.
Suspicion of fraud, delinquency or bad account management should trigger change the Offline Risk Parameters.
To do this effectively requires comprehensive links and interaction between the various back office processes including Account Management, Fraud Detection, Card Management, Customer Services and Risk Management and EMV Application Parameter Management systems through the core transaction handling system.
EMV Data In Authorisation
We have discuss the operational environment as far as using EMV data in the authorisation process.
You need to expose the EMV data to the authorisation decision and determine the wider proposition.
EMV Data In Risk Management
The area I am concentrating on in this section is the Risk Management system. Expose the EMV data Risk Management.
It is vital that we use the EMV data provided to us - it provides us with invaluable additional information about the transaction, the card and the environment in which the transaction is conducted - which we should utilise to our benefit.
The enhanced authorisation service will send transactions to the Risk Management system.
When it sends the transaction, it can optionally flag the transaction as suspicious, the Risk Management system can then perform the necessary analysis.
Proactive Risk Manager (PRM)
A proactive risk management software should support a comprehensive EMV enabled risk management system with features such as
- Real Time actions
- Real Time - proactive and dynamic
- Integrates easily to Enhanced Authorisation Processes (EAS), Application Parameter Manager (APM) systems
- Neural technology and flexible rules system
Try and utilised an EMV enabled Risk Management System - Proactive Risk Manager which has been EMV enabled for a few more years.
Irrespective of the Risk Management System that is utilised, what minimum features should a comprehensive EMV enabled Risk Management System have?
Real Time Analysis, so that the transaction can be analysed with the EMV data as part of the authorisation process.
Its quite obvious that if you can either decline or refer a fraudulent transaction, not only do you save on the fraud itself, you also save on all the other associated costs.
The re-issuing of the card, spending time on the case management, possible chargebacks and the general customer services effort.
Today many organisations are reluctant to stop transactions in real time - they do not want to upset genuine customers and is a real customer service issue.
However, by analysing the EMV data provided as part of the authorisation, you will be able to make a much more informed decision than you are capable of today.
You can determine the authenticity of the card, the cardholder and the environment the transaction is taking place in.
As well as utilising a flexible and comprehensive rules system, advanced analytics are required to detect the very subtle changes in customer behaviour.
Whilst rules can be utilised for this purpose - neural networks are excellent at detecting subtle changes in behaviour.
Its great to have a Risk Management System with all the bells and whistles with regards to functionality.
However, if it cannot easily be integrated with the Enhanced Authorisation Processes it will become difficult to analyse the transaction in a timely manner.
You need to ensure that the EAS system is capable of not only sending EMV data to the Risk Management System, but can also flag those transactions that it feels need further detailed analysis.
For example, the EAS process has determined that the card has a chip on board, the terminal is chip enabled, but the transaction was conducted in fallback mode.
Once this transaction comes through to PRM, PRM can then check the transaction history and can look for trends, such as - how many fallbacks have you had with this card?
How many fallbacks at this merchant? Is there a chip failure on this card or has the original card been compromised. Is the transaction consistent with the customer's trends etc. etc.
What about the Application parameter system?
You need to be able to flag changes to the parameters on the card - the Upper and Lower Consecutive Online Limits and so on.
PRM needs to integrate with the APM system, so that analysts can force those cards online that is deems suspicious as well as be able to send other scripts to the chip - suspend application, block card and so on.
It would be very beneficial if the risk management system could perform actions in real time - what you mean by this is actions such as blocking the card or generating EMV scripts automatically when certain events are detected by the system.
Proactive & Integrated Risk Management Solutions
Any proactive and integrated risk management software solutions MUST exhibit the following:
- Ability to analyse the EMV data
- Ability to monitor across accounts
- Ability to monitor and analyse trends in failure, incidence of fallback, etc.
- Ability to monitor for application fraud and account take-over
- Ability to monitor transactions against customer behaviour
- React both proactively and dynamically
One thing is for certain - during the migration to EMV and post EMV, your risk management environment needs to get more sophisticated and integrated with other systems.
There will be new trends to look for, as well as the ability to make sense of the EMV data you are presented with and be able to do something about it.
You need to continue to monitor transactions against customer behaviour, but need to take into account the new trends.
Your neural detection and rules need to change to take these into account.
For example, if your Enhanced Authorisation Process has flagged that a certain transaction needs to be analysed immediately for risk, your risk management system should perform the necessary analysis.
Including checking the offline transactions against the normal behaviour of that cardholder.
A more comprehensive risk management environment will be one where you have the ability to monitor across all of the customers accounts - thereby taking an enterprise wide view.
Today, Risk Management tends to be done in solios - separately for the different products.
Taking a customer centric view of fraud provides you with the ability to defend against fraud at all transaction channels, as well as across all accounts at the customer level.
As well as giving you a better picture of each customer's behaviour, it will also enable you to tackle application fraud and account takeover activities more effectively.
Your risk management system should also be able to monitor trends in failure.
For example, chip card reader failure in terminals, incidences of fallback - how often, when and where?
This can be used to determine trends and can assist in discovering points of compromise.
Likewise, any risk management system should be able to analyse the EMV data from a risk perspective and act upon it.
For example your risk management system should be expanded to react to unusual card activity and recommend specific actions to be taken with the card.
Such as to create and download an EMV parameter change to the debit or credit card application.
The EMV Data:-
- 50 to 60 extra data items - all associated with risk management
- ARQC Verify
- CVR - Card Verify Results
- Data Suspect
- EMV Terminal Type
- Last EMV Status
- Point of Service Entry Mode
- Reason Online Code
- TVR - Terminal Verify Results
Risk Management Enviroment
The Transaction Flow
How does an EMV Enabled Risk Management System environment might look like?
Firstly, lets look at a near real time environment. This refers to analysis of a transaction for risk after it has been authorised.
If a rule in PRM is triggered, an alert is generated and forwarded to an analyst, who will review it.
Lets assume the analyst comes to the conclusion that the original card has been compromised and should be blocked.
The analyst can perform a tie-back operation from PRM to block the card in the authorization system. This will ensure that further online transactions will be defined.
However, offline transactions can still be performed, so the application on the chip has to be blocked.
The analyst can initiate a Block Script request to the Application Parameter Management System. This will deliver the script to the card the next time it is presented online.
We just described a near real time environment. Lets consider a real time environment.
This is where a transaction is analysed for risk during the authorisation process.
In real time mode, PRM can also perform auto actions - so a card block and a block scipt can be generated automatically without any manual intervention. This is a very powerful and effective tool against fraud.
This type of environment will be very useful for those banks that do not have a 24 x 7 fraud shop.
The integration of the front-end and back-office systems to provide a comprehensive END to END risk managed environment will provide the enterprise with a fully risk averse environment.
In Summary, What is required is a fully integrated environment - this includes the authorisation system , the risk management and application parameter system.
EMV gives you an opportunity to make a much more informed decision - in order to do this, the EMV data needs to be considered for risk.
The Risk Management System, the procedures and process need to be enhanced in readiness for the changing face of fraud that is inevitable in the EMV world.
Any Risk Management Offering should already be EMV enables and support EMV Template Rules to customers of PRM.
Examples of Other Uses of EMV Data
Here are other uses of EMV data:
- PIN Entry Req, PIN Pad Present, But PIN Was Not Entered (TVR)
- Iss-Script-Data (script download failed?)
- 1504- Terminal Not Able to Process ICC
- 1511 - Merchant Suspicious
A few other examples of how EMV data can be utilised in a Risk Management System.
The PIN Entry Required, PIN Pad present, But PIN Was Not Entered flag can point to merchant collusion or a rogue employee at the merchant.
The Iss-Script-Data can inform us if the script update has worked. We need to determine what type of script has failed - a script failure does not necessarily means we need to be concerned.
For example, if a script to increase the UCOL value on the chip has failed then from a risk perspective you would not be too concerned. However, if a block script fails, then you would be more interested in why.
If the acquirer is suspicious, then they can set the Data-Suspect flag. You can check this in the Risk Management system and perform further analysis if required.
The Reason-Online-Code informs us why the transaction was sent online. If either of the 2 flags listed are set, this would require us to undertake further analysis.