Recherche avancée

Sur d’autres sites (3984)

• A Quick Start Guide to the Payment Services Directive (PSD2)

  22 novembre 2024, par Daniel Crough — Banking and Financial Services, Privacy

  In 2023, there were 266.2 billion real-time payments indicating that the demand for secure transactions has never been higher. As we move towards a more open banking system, there are a host of new payment solutions that offer convenience and efficiency, but they also present new risks.

  The Payment Services Directive 2 (PSD2) is one of many regulations established to address these concerns. PSD2 is a European Union (EU) business initiative to offer smooth payment experiences while helping customers feel safe from online threats. 

  In this post, learn what PSD2 includes, how it improves security for online payments, and how Matomo supports banks and financial institutions with PSD2 compliance.

  What is PSD2 ? 

  PSD2 is an EU directive that aims to improve the security of electronic payments across the EU. It enforces strong customer authentication and allows third-party access to consumer accounts with explicit consent. 

  Its main objectives are :

  • Strengthening security and data privacy measures around digital payments.
  • Encouraging innovation by allowing third-party providers access to banking data.
  • Improving transparency with clear communication regarding fees, terms and conditions associated with payment services.
  • Establishing a framework for sharing customer data securely through APIs for PSD2 open banking.

  Rationale behind PSD2 

  PSD2’s primary purpose is to engineer a more integrated and efficient European payment market without compromising the security of online transactions. 

  The original directive aimed to standardise payment services across EU member states, but as technology evolved, an updated version was needed.

  PSD2 is mandatory for various entities within the European Economic Area (EEA), like :

  • Banks and credit institutions
  • Electronic money institutions or digital banks like Revolut
  • Card issuing and acquiring institutions
  • Fintech companies
  • Multi-national organisations operating in the EU

  PSD2 implementation timeline

  With several important milestones, PSD2 has reshaped how payment services work in Europe. Here’s a closer look at the pivotal events that paved the way for its launch.

  • 2002 : The banking industry creates the European Payments Council (EC), which drives the Single Euro Payments Area (SEPA) initiative to include non-cash payment instruments across European regions. 
  • 2007 : PSD1 goes into effect.
  • 2013 : EC proposes PSD2 to include protocols for upcoming payment services.
  • 2015 : The Council of European Union passes PSD2 and gives member states two years to incorporate it.
  • 2018 : PSD2 goes into effect. 
  • 2019 : The final deadline for all companies within the EU to comply with PSD2’s regulations and rules for strong customer authentication. 

  PSD2 : Key components 

  PSD2 introduces several key components. Let’s take a look at each one.

  Strong Customer Authentication (SCA)

  The Regulatory Technical Standards (RTS) under PSD2 outline specific requirements for SCA. 

  SCA requires multi-factor authentication for online transactions. When customers make a payment online, they need to verify their identity using at least two of the three following elements :

  • Knowledge : Something they know (like a password, a code or a secret answer)
  • Possession : Something they have (like their phone or card)
  • Inherence : Something they are (like biometrics — fingerprints or facial features)

  

  Before SCA, banks verified an individual’s identity only using a password. This dual verification allows only authorised users to complete transactions. SCA implementation reduces fraud and increases the security of electronic payments.

  SCA implementation varies for different payment methods. Debit and credit cards use the 3D Secure (3DS) protocol. E-wallets and other local payment measures often have their own SCA-compliant steps. 

  3DS is an extra step to authenticate a customer’s identity. Most European debit and credit card companies implement it. Also, in case of fraudulent chargebacks, the issuing bank becomes liable due to 3DS, not the business. 

  However, in SCA, certain transactions are exempt : 

  • Low-risk transactions : A transaction by an issuer or an acquirer whose fraud level is below a specific threshold. If the acquirer feels that a transaction is low risk, they can request to skip SCA. 
  • Low-value transactions : Transactions under €30.
  • Trusted beneficiaries : Trusted merchants customers choose to safelist.
  • Recurring payments : Recurring transactions for a fixed amount are exempt from SCA after the first transaction.

  Third-party payment service providers (TPPs) framework

  TPPs are entities authorised to access customer banking data and initiate payments. There are three types of TPPs :

  Account Information Service Providers (AISPs)

  AISPs are services that can view customers’ account details, but only with their permission. For example, a budgeting app might use AISP services to gather transaction data from a user’s bank account, helping them monitor expenses and oversee finances. 

  Payment Initiation Service Providers (PISPs)

  PISPs enable clients to initiate payments directly from their bank accounts, bypassing the need for conventional payment options such as debit or credit cards. After the customer makes a payment, PISPs immediately contact the merchant to ensure the user can access the online services or products they bought. 

  Card-Based Payment Instruments (CBPII)

  CBPIIs refer to services that issue payment cards linked to customer accounts. 

  Requirements for TPPs

  To operate effectively under PSD2, TPPs must meet several requirements :

  Consumer consent : Customers must explicitly authorise TPPs to retrieve their financial data. This way, users can control who can view their information and for what purpose.

  Security compliance : TPPs must follow SCA and secure communication guidelines to protect users from fraud and unauthorised access.

  API availability : Banks must make their Application Programming Interfaces (APIs) accessible and allow TPPs to connect securely with the bank’s systems. This availability helps in easy integration and lets TPPs access essential data. 

  Consumer protection methods

  PSD2 implements various consumer protection measures to increase trust and transparency between consumers and financial institutions. Here’s a closer look at some of these key methods :

  • Prohibition of unjustified fees : PSD2 requires banks to clearly communicate any additional charges or fees for international transfers or account maintenance. This ensures consumers are fully aware of the actual costs and charges.
  • Timely complaint resolution : PSD2 mandates that payment service providers (PSPs) have a straightforward complaint procedure. If a customer faces any problems, the provider must respond within 15 business days. This requirement encourages consumers to engage more confidently with financial services.
  • Refund in case of unauthorised payment : Customers are entitled to a full refund for payments made without their consent.
  • Surcharge ban : Additional charges on credit and debit card payments aren’t allowed. Businesses can’t impose extra fees on these payment methods, which increases customers’ purchasing power.

  Benefits of PSD2 

  Businesses — particularly those in banking, fintech, finserv, etc. — stand to benefit from PSD2 in several ways.

  Access to customer data

  With customer consent, banks can analyse spending patterns to develop tailored financial products that match customer needs, from personalised savings accounts to more relevant loan offerings.

  Innovation and cost benefits 

  PSD2 opened payment processing up to more market competition. New payment companies bring fresh approaches to banking services, making daily transactions more efficient while driving down processing fees across the sector.

  Also, banks now work alongside payment technology providers, combining their strengths to create better services. This collaboration brings faster payment options to businesses, helping them stay competitive while reducing operational costs.

  Improved customer trust and experience

  Due to PSD2 guidelines, modern systems handle transactions quickly without compromising the safety of payment data, creating a balanced approach to digital banking.

  

  Banking customers now have more control over their financial information. Clear processes allow consumers to view and adjust their financial preferences as needed.

  Strong security standards form the foundation of these new payment systems. Payment provider platforms must adhere to strict regulations and implement additional protection measures.

  Challenges in PSD2 compliance 

  What challenges can banks and financial institutions face regarding PSD2 compliance ? Let’s examine them. 

  Resource requirements

  For many businesses, the new requirements come with a high price tag. PSD2 requires banks and fintechs to build and update their systems so that other providers can access customer data safely. For example, they must develop APIs to allow TPPs to acquire customer data. 

  Many banks still use older systems that can’t meet PSD2’s added requirements. In addition to the cost of upgrades, complying with PSD2 requires banks to devote resources to training staff and monitoring compliance.

  The significant costs required to update legacy systems and IT infrastructure while keeping services running remain challenging.

  Risks and penalties

  Organisations that fail to comply with PSD2 regulations can face significant penalties.

  Additionally, the overlapping requirements of PSD2 and other regulations, such as the General Data Protection Regulation (GDPR), can create confusion. 

  Banks need clear agreements with TPPs about who’s responsible when things go wrong. This includes handling data breaches, preventing data misuse and protecting customer information. 

  Increased competition 

  Introducing new players in the financial ecosystem, such as AISPs and PISPs, creates competition. Banks must adapt their services to stay competitive while managing compliance costs.

  PSD2 aims to protect customers but the stronger authentication requirements can make banking less convenient. Banks must balance security with user experience. Focused time, effort and continuous monitoring are needed for businesses to stay compliant and competitive.

  How Matomo can help 

  Matomo gives banks and financial institutions complete control over their data through privacy-focused web analytics, keeping collected information internal rather than being used for marketing or other purposes. 

  Its advanced security setup includes access controls, audit logs, SSL encryption, single sign-on and two-factor authentication. This creates a secure environment where sensitive data remains accessible only to authorised staff.

  While prioritizing privacy, Matomo provides tools to understand user flow and customer segments, such as session recordings, heatmaps and A/B testing.

  Financial institutions particularly benefit from several key features : 

  • Tools for obtaining explicit consent before processing personal data like this Do Not Track preference
  • Insights into how financial institutions integrate TPPs (including API usage, user engagement and potential authentication drop-off points)
  • Tracking of failed login attempts or unusual access patterns
  • IP anonymization to analyse traffic patterns and detect potential fraud

  

  PSD3 : The next step 

  In recent years, we have seen the rise of innovative payment companies and increasingly clever fraud schemes. This has prompted regulators to propose updates to payment rules.

  PSD3’s scope is to adapt to the evolving digital transformation and to better handle these fraud risks. The proposed measures : 

  • Encourage PSPs to share fraud-related information.
  • Make customers aware of the different types of fraud.
  • Strengthen customer authentication standards.
  • Provide non-bank PSPs restricted access to EU payment systems. 
  • Enact payment rules in a directly applicable regulation and harmonise and enforce the directive.

  Web analytics that respect user privacy 

  Achieving compliance with PSD2 may be a long road for some businesses. With Matomo, organisations can enjoy peace of mind knowing their data practices align with legal requirements.

  Ready to stop worrying over compliance with regulations like PSD2 and take control of your data ? Start your 21-day free trial with Matomo.

• A Guide to GDPR Sensitive Personal Data

  13 mai 2024, par Erin

  The General Data Protection Regulation (GDPR) is one of the world’s most stringent data protection laws. It provides a legal framework for collection and processing of the personal data of EU individuals.

  The GDPR distinguishes between “special categories of personal data” (also referred to as “sensitive”) and other personal data and imposes stricter requirements on collection and processing of sensitive data. Understanding these differences will help your company comply with the requirements and avoid heavy penalties.

  In this article, we’ll explain what personal data is considered “sensitive” according to the GDPR. We’ll also examine how a web analytics solution like Matomo can help you maintain compliance.

  What is sensitive personal data ?

  The following categories of data are treated as sensitive :

  1. 1. Personal data revealing :
        • Racial or ethnic origin ;
        • Political opinions ;
        • Religious or philosophical beliefs ;
        • Trade union membership ;
     2. Genetic and biometric data ;
     3. Data concerning a person’s :
        • Health ; or
        • Sex life or sexual orientation.

  

  Sensitive vs. non-sensitive personal data : What’s the difference ?

  While both categories include information about an individual, sensitive data is seen as more private, or requiring a greater protection. 

  Sensitive data often carries a higher degree of risk and harm to the data subject, if the data is exposed. For example, a data breach exposing health records could lead to discrimination for the individuals involved. An insurance company could use the information to increase premiums or deny coverage. 

  In contrast, personal data like name or gender is considered less sensitive because it doesn’t carry the same degree of harm as sensitive data. 

  Unauthorised access to someone’s name alone is less likely to harm them or infringe on their fundamental rights and freedoms than an unauthorised access to their health records or biometric data. Note that financial information (e.g. credit card details) does not fall into the special categories of data.

  

  Legality of processing

  Under the GDPR, both sensitive and nonsensitive personal data are protected. However, the rules and conditions for processing sensitive data are more stringent.

  Article 6 deals with processing of non-sensitive data and it states that processing is lawful if one of the six lawful bases for processing applies. 

  In contrast, Art. 9 of the GDPR states that processing of sensitive data is prohibited as a rule, but provides ten exceptions. 

  It is important to note that the lawful bases in Art. 6 are not the same as exceptions in Art. 9. For example, while performance of a contract or legitimate interest of the controller are a lawful basis for processing non-sensitive personal data, they are not included as an exception in Art. 9. What follows is that controllers are not permitted to process sensitive data on the basis of contract or legitimate interest. 

  The exceptions where processing of sensitive personal data is permitted (subject to additional requirements) are : 

  • Explicit consent : The individual has given explicit consent to processing their sensitive personal data for specified purpose(s), except where an EU member state prohibits such consent. See below for more information about explicit consent. 
  • Employment, social security or social protection : Processing sensitive data is necessary to perform tasks under employment, social security or social protection law.
  • Vital interests : Processing sensitive data is necessary to protect the interests of a data subject or if the individual is physically or legally incapable of consenting. 
  • Non-for-profit bodies : Foundations, associations or nonprofits with a political, philosophical, religious or trade union aim may process the sensitive data of their members or those they are in regular contact with, in connection with their purposes (and no disclosure of the data is permitted outside the organisation, without the data subject’s consent).
  • Made public : In some cases, it may be permissible to process the sensitive data of a data subject if the individual has already made it public and accessible. 
  • Legal claims : Processing sensitive data is necessary to establish, exercise or defend legal claims, including legal or in court proceedings.
  • Public interest : Processing is necessary for reasons of substantial public interest, like preventing unlawful acts or protecting the public.
  • Health or social care : Processing special category data is necessary for : preventative or occupational medicine, providing health and social care, medical diagnosis or managing healthcare systems.
  • Public health : It is permissible to process sensitive data for public health reasons, like protecting against cross-border threats to health or ensuring the safety of medicinal products or medical devices. 
  • Archiving, research and statistics : You may process sensitive data if it’s done for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes.

  In addition, you must adhere to all data handling requirements set by the GDPR.

  Important : Note that for any data sent that you are processing, you always need to identify a lawful basis under Art. 6. In addition, if the data sent contains sensitive data, you must comply with Art. 9.

  Explicit consent

  While consent is a valid lawful basis for processing non-sensitive personal data, controllers are permitted to process sensitive data only with an “explicit consent” of the data subject.

  The GDPR does not define “explicit” consent, but it is accepted that it must meet all Art. 7 conditions for consent, at a higher threshold. To be “explicit” a consent requires a clear statement (oral or written) of the data subject. Consent inferred from the data subject’s actions does not meet the threshold. 

  The controller must retain records of the explicit consent and provide appropriate consent withdrawal method to allow the data subject to exercise their rights.

  Examples of compliant and non-compliant sensitive data processing

  Here are examples of when you can and can’t process sensitive data :

  • When you can process sensitive data : A doctor logs sensitive data about a patient, including their name, symptoms and medicine prescribed. The hospital can process this data to provide appropriate medical care to their patients. An IoT device and software manufacturer processes their customers’ health data based on explicit consent of each customer. 
  • When you can’t process sensitive data : One example is when you don’t have explicit consent from a data subject. Another is when there’s no lawful basis for processing it or you are collecting personal data you simply do not need. For example, you don’t need your customer’s ethnic origin to fulfil an online order.

  Other implications of processing sensitive data

  If you process sensitive data, especially on a large scale, GDPR imposes additional requirements, such as having Data Privacy Impact Assessments, appointing Data Protection Officers and EU Representatives, if you are a controller based outside the EU.

  Penalties for GDPR non-compliance

  Mishandling sensitive data (or processing it when you’re not allowed to) can result in huge penalties. There are two tiers of GDPR fines :

  • €10 million or 2% of a company’s annual revenue for less severe infringements
  • €20 million or 4% of a company’s annual revenue for more severe infringements

  In the first half of 2023 alone, fines imposed in the EU due to GDPR violations exceeded €1.6 billion, up from €73 million in 2019.

  Examples of high-profile violations in the last few years include :

  • Amazon : The Luxembourg National Commission fined the retail giant with a massive $887 million fine in 2021 for not processing personal data per the GDPR. 
  • Google : The National Data Protection Commission (CNIL) fined Google €50 million for not getting proper consent to display personalised ads.
  • H&M : The Hamburg Commissioner for Data Protection and Freedom of Information hit the multinational clothing company with a €35.3 million fine in 2020 for unlawfully gathering and storing employees’ data in its service centre.

  One of the criteria that affects the severity of a fine is “data category” — the type of personal data being processed. Companies need to take extra precautions with sensitive data, or they risk receiving more severe penalties.

  What’s more, GDPR violations can negatively affect your brand’s reputation and cause you to lose business opportunities from consumers concerned about your data practices. 76% of consumers indicated they wouldn’t buy from companies they don’t trust with their personal data.

  Organisations should lay out their data practices in simple terms and make this information easily accessible so customers know how their data is being handled.

  Get started with GDPR-compliant web analytics

  The GDPR offers a framework for securing and protecting personal data. But it also distinguishes between sensitive and non-sensitive data. Understanding these differences and applying the lawful basis for processing this data type will help ensure compliance.

  Looking for a GDPR-compliant web analytics solution ?

  At Matomo, we take data privacy seriously. 

  Our platform ensures 100% data ownership, putting you in complete control of your data. Unlike other web analytics solutions, your data remains solely yours and isn’t sold or auctioned off to advertisers. 

  Additionally, with Matomo, you can be confident in the accuracy of the insights you receive, as we provide reliable, unsampled data.

  Matomo also fully complies with GDPR and other data privacy laws like CCPA, LGPD and more.

  Start your 21-day free trial today ; no credit card required. 

  Disclaimer

  We are not lawyers and don’t claim to be. The information provided here is to help give an introduction to GDPR. We encourage every business and website to take data privacy seriously and discuss these issues with your lawyer if you have any concerns.

  Try Matomo for Free

  21 day free trial. No credit card required.

  
  

  Your email address
  

  Your website address
  

  Your Analytics subdomain will be .matomo.cloud (change)

  Choose your analytics subdomain
  

  .matomo.cloud

  I accept the terms and conditions and data processing agreement (DPA)

  
  Your information will be used to create an account on our cloud service. For more information please consult our privacy policy.
  
  
  

  Start improving your websites now

  

• Concatenate chunk containg headers to another chunk in h264

  18 novembre 2014, par Ortixx

  I’m trying to extract thumbnails from a torrent stream by downloading the first couple of chunks to get the headers, another set of chunks from the middle and then concat them to have a single video file.

  For this I’m using nodejs but I’m having trouble with the concatenation part. Obviously the headers include the length of the video so if I simply concat another chunk to the end of the headers chunk, it won’t work.

  In other words, I have 2 chunks of a video file : The first one contains the headers and some material and the other one is fully composed of a video stream. I want to combine the two to form a single video file
  So my question is how can I make this work properly if at all ?