# Support
source: https://developer.mastercard.com/identity-insights-for-transactions/documentation/support/index.md

## FAQ {#faq}

\*\* Identity Insights for Transactions \*\*
Mastercard Identity Insights for Transactions (IIT) provides rich, actionable individual and device insights that can help business optimize transaction risk routing. This enables frictionless commerce for customers and improves both pre- and post authorization decisioning. Businesses can use the scores, accompanying metadata, or reason codes separately, and together, depending on the use case you are looking to solve and how each feature performs in your model. We advise using the scores alongside the other top predictive signals accompanying each insight type to finetune your models.

#### Identity Insights: {#identity-insights}

**Identity Risk Score**   

Based on five core attributes (name, email, address, phone, and IP) leveraging data sources with 7+ billion identity elements and 5+ billion digital interactions.  

**IP Score**   

Assesses the risk of a given IP address in real-time, as well as network data that surfaces the IP address' previous use.   

**Predictive Signals**   

Additional metadata that provides more detail and context to help in enhancing risk decisions.   

#### Device Insights: {#device-insights}

**Insight Factor**   

An integer between 1-5 (1 being no insight rules triggered, 5 being high-velocity events seen). This value reflects the highest seen insight level and event available in the request.  

**Trust Factor**   

An integer between 1-5 (1 being no trust and 5 being high trust). The trust factor value reflects the trustworthiness of the attributes associated with this device.   

**Risk Factor**   

An integer between 0-5 (0 being no history, 1 being low risk, 5 being high risk) from our consortium of device network data.   
Optimally, merchants, and EEA acquirers, or their PSPs or fraud platform providers, looking to utilize customer-given information to expedite their buying journey, improve pre- and post-authorization decisioning outcomes and combine device information from increasingly mobile-first customers would benefit from IIT.

#### Global Merchants {#global-merchants}

While merchants have access to many customer identity elements, utilizing that data to make the best decisions without broad context makes it difficult to assess the risk of those elements when used together. IIT removes that difficulty by allowing businesses to evaluate customer-given elements against up-to-date and validated identity elements and device-centric identification insights that fuel transaction decisioning platforms or workflows to support several different outcomes.

* Increase ecommerce transaction security through improved identification of fraudulent identity data.
* Reduce fraud by enhancing risk models with better data.
* Improved visibility into the information issuers might receive when assessing authorization.
* Decrease the potential for revenue-depleting chargebacks by providing customers with the rich insights necessary to help establish confidence in transaction authenticity.
* Reduce acquirer risk by keeping their merchant portfolio fraud rate low via models or rules.
* Identify good customers with global data insights.
* Reduce false declines.
* Grow customer intelligence for companies looking to expand beyond their established territories.

#### EU-based Merchants and Acquirers {#eu-based-merchants-and-acquirers}

* Help optimize Transaction Risk Analysis exemptions from PSD2.
* Reduce friction by ensuring that Strong Customer Authentication (SCA) is applied to higher-risk transactions.

#### Payment Service Providers or Fraud Platforms {#payment-service-providers-or-fraud-platforms}

* Enhance insights for improved risk decision products, platforms, or services offered to merchant customers.
* Leverage individual and device insights across all payment networks.
* Gain rich, actionable insights on all browser or mobile-based, card-not-present transactions.
* Optimize PSD2 Transaction Risk Analysis exemptions to reduce consumer friction, maintain low fraud rates, and increase approvals.
* Reduce unnecessary consumer friction from Strong Customer Authentication.
IIT can be used in both pre and post-authorization workflow.   
**Pre-authorization scenario:**   
IIT deployment may take place in the transaction workflow after the cardholder sends their credit card information to the merchant, payment center, and/or acquiring bank before sending it to the issuer. As a transaction analysis requires data, processing, and decision-making, the business needs to ensure that its decision is based upon the right information with the least amount of time for the customer. The pre-authorization scenario can also take place before authentication, for customers who utilize EMV 3DS on some or all transactions.  
**Post-authorization scenario:**   
IIT offers risk-related scores and additional metadata that can be used for risk analysis that aren't limited by short-latency, or pre-authorization requirements. Here, the transaction risk analysis might require additional time to confirm a fraudulent transaction after the issuer has authorized the payment. In this scenario, customers experience the least amount of friction in their buying experience and the business can perform due diligence research, send to manual review, or reject the transaction.  
Despite being a Mastercard product, IIT is brand agnostic, feeding intelligence back to the customer regardless of card brand. This allows businesses to leverage individual and device insights across all card networks.
* Payment Services Directive Two(PSD2) RTS stands for the EU Payment Services Directive 2 Regulatory Technical Standards that was published in 2018.
* Payment Services Directive Two(PSD2) RTS requires that Strong Customer Authentication (SCA) must be used for all remote electronic transactions (including ecommerce) unless an exemption applies (please see below for details).
* Merchants must send authentication requests using the EMV 3-D Secure (EMV 3DS) protocol to avoid issuers declining e-commerce transactions. According to several surveys, around 20% of large issuers have indicated that post-RTS, non-EMV 3DS transactions will be declined to avoid non-compliance.
* The RTS will apply in the 31 countries which make up the European Economic Area or EEA (28 EU countries plus Norway, Iceland, and Liechtenstein).
Strong Customer Authentication (SCA) is a European (and UK) regulatory requirement to make digital payments more secure. To ensure SCA readiness and continue accepting digital payments, merchants in these regions must include additional authentication into a customer's checkout process. In more practical terms, SCA means authentication based on the use of two or more independent elements (aka "factors") that fall under three categories: 'knowledge', 'possession', or 'inherence'. Payment Services Directive Two(PSD2) requires all EEA transactions to go through SCA unless the transaction can be successfully flagged for an exemption. For acquirers and issuers, PSD2 also requires that Transaction Risk Analysis (TRA) is performed, regardless of exemptions, even when they bypass authentication. For EUR merchants and acquirers, IIT provides predictive insights to optimize their SCA exemptions. For customers, they'll increase their confidence that transactions submitted for authorization with an exemption will be approved. Also, the expanded, safe use of SCA exemptions helps to improve the overall customer experience by reducing unnecessary friction for consumer transactions. This product follows a progressive tiered price-per-query model. This product is available in all regions. EU customers should use idv.mastercard.eu. South East Asia customers should use idv.mastercard.asia. Australia customers should use idv.mastercard.com.au. Other regions should use idv.mastercard.com IIT customers utilize a single API integration that delivers identity and device details in a single payload. Mastercard teams will assist customers during integration to ensure that they can effectively move to production, after which Mastercard offers 24/7 technical support to ensure that IIT effectively meets customer needs.  
IIT can be used pre-authentication, pre-authorization, or post-authorization to provide the customer with rich risk insights to inform decisioning. Yes, all IIT customers will be required to have a CID and billable ICA. Customers can connect with their Mastercard representative to ensure that Franchise onboarding processes are followed to obtain a CID and ICA to invoice for the service. SLA for the project approval is 5 days. If the SLA is not met the appropriate Mastercard representative will reach out to you.

**API Specific**
There are two environments where onboarding will be performed, Sandbox environment where all the tests and pre-production validations will happen, and the production environment which will be used for commercial deployments. Mutual Transport Layer Security (MTLS) Message-level encryption is required to consume this API. The client needs to encrypt the request using the Mastercard's public key which can be downloaded from the client project created in MC Developers. The customer needs to request a client certificate for the sandbox environment via the Key Management Portal (KMP), a tool within Mastercard Connect. Subsequently, the customer registers with the Mastercard Developer portal and requests access to Identity Insights for Transactions API and uploads the MTLS Client Certificate. The customer must receive the Certificate and Project approval email notification before proceeding. The customer needs to call the following Sandbox URLs with encrypted payload.

* EU customers: sandbox.idv.mastercard.eu   
* SEA customers: sandbox.idv.mastercard.asia   
* Other customers: sandbox.idv.mastercard.com   

**Production URLs**

* EU customers: idv.mastercard.eu  
* SEA customers: idv.mastercard.asia  
* Other customers: idv.mastercard.com  
No. You will need separate certificates. Yes. You may use the same certificate (For example, Sandbox or Production) for other products within the same Identity Insights suite. Customers can provide either account number, Network Token, or the Last 4 + Expiry. MTLS certificates are valid for two years while the Mastercard Developers encryption keys are valid for one year. The KMP will provide numerous warnings, starting 120 days before expiration. Mastercard Developers will provide notification to the user starting 30 days before expiration.

**Metrics**
The client service does not need to be PCI compliant to access the IIT API. PCI and PII data is handled following the PCI security guidelines to ensure the application complies with the PCI DSS standards. Yes. IIT will process the request as a new request and will not return any duplicate data error.

**Response Data FAQ**
Error descriptions can be found in the Mastercard Developers [Code and Formats section](https://developer.mastercard.com/identity-insights-for-transactions/documentation/code-and-formats/index.md). iOS or Indian on Soil transactions refer to Cross-Border outbound transactions that are out of scope for regulatory reasons from transmitting Identity and Device insights at this time. Cross-Border Outbound transactions are transactions on an Indian issued card, but with a foreign acquirer and foreign merchant. Response descriptions can be found in the Mastercard Developers [Parameters page](https://developer.mastercard.com/identity-insights-for-transactions/documentation/parameters/index.md). Submit a support request ticket to the standard [Customer Technical Support channel](mailto:support@ekata.com:) and be sure to include the Correlation ID (the overall transaction ID) as well as the unexpected value or score. The more information provided from the origination of the support ticket will help to expedite an effective response. Multiple IDs are autogenerated in the API response:   
**ID:**   
This is the unique identifier for the overall transaction query. This can be used to tie transactions to outcomes, tracking in internal systems, etc. This is the same transaction ID as the "Correlation ID" below.  
**Device Insights ID:**   
This is the unique identifier for the device and can be used to track in internal systems.  
**dsTransID:**   
This is the unique transaction identifier assigned by the Directory Server, available only for Mastercard transactions. This can be used to match the transaction in authentication/authorization that issuers will see.  
**Correlation ID:**   
This is the unique identifier generated by Mastercard for each transaction and it will be passed in the HTTP header. This is the same transaction ID as the "ID" above.  

**Pricing and Billing**
Mastercard will bill Customer Fees regularly through the Mastercard Consolidated Billing System (MCBS). MCBS stands for Mastercard Consolidated Billing Services. The MCBS is the system that Mastercard will use to calculate and generate a monthly bill. Since Mastercard bills are in arrears, we are billing for the preceding month. Mastercard will generate the invoice on the second Sunday of every month for the preceding month's activity. Billing for the IIT service will begin once the customer has moved to production. There may be a fee assessed by the customer delivery team conducting the onboarding and integration, which will be detailed during the contracting phase if applicable.

**Contact and Access**
Please write to [Mastercard support team](mailto:TII.support@mastercard.com?subject=Mastercard%20TII%3A) for more information about IIT. Please write to [Mastercard support team](mailto:TII.support@mastercard.com?subject=Mastercard%20TII%3A) for any technical query. Customers should provide CTS representatives with the IIT Transaction ID or Correlation ID of the transaction and any associated error or warning messages that they have received. Customers should also provide the environment being called and URL (EU or non-EU). Refer [Access MC connect](https://static.developer.mastercard.com/content/identity-insights-for-transactions/ConnectOverview.pdf). Refer [Access KMP portal](https://static.developer.mastercard.com/content/identity-insights-for-transactions/KMP-User-Guide.pdf).

**Acronyms**

EEA - European Economic Area   

EU - Europe   

EMV - Europay, Mastercard and Visa   

3DS - 3-D Secure Authentication   

RTS - Regulatory Technical Standards   

CTS - Customer Technical Support   

IIT - Identity Insights for Transactions   

## Get Help {#get-help}

### Contact us for technical support. {#contact-us-for-technical-support}

Get Help