Recherche avancée

Sur d’autres sites (8380)

• Banking Data Strategies – A Primer to Zero-party, First-party, Second-party and Third-party data

  25 octobre 2024, par Daniel Crough — Banking and Financial Services, Privacy

  Banks hold some of our most sensitive information. Every transaction, loan application, and account balance tells a story about their customers’ lives. Under GDPR and banking regulations, protecting this information isn’t optional – it’s essential.

  Yet banks also need to understand how customers use their services to serve them better. The solution lies in understanding different types of banking data and how to handle each responsibly. From direct customer interactions to market research, each data source serves a specific purpose and requires its own privacy controls.

  Before diving into how banks can use each type of data effectively, let’s look into the key differences between them :

  Data Type	What It Is	Banking Example	Legal Considerations
  First-party	Data from direct customer interactions with your services	Transaction records, service usage patterns	Different legal bases apply (contract, legal obligation, legitimate interests)
  Zero-party	Information customers actively provide	Stated preferences, financial goals	Requires specific legal basis despite being voluntary ; may involve profiling
  Second-party	Data shared through formal partnerships	Insurance history from partners	Must comply with PSD2 and specific data sharing regulations
  Third-party	Data from external providers	Market analysis, demographic data	Requires due diligence on sources and specific transparency measures

  What is first-party data ?

  

  First-party data reveals how customers actually use your banking services. When someone logs into online banking, withdraws money from an ATM, or speaks with customer service, they create valuable information about real banking habits.

  This direct interaction data proves more reliable than assumptions or market research because it shows genuine customer behaviour. Banks need specific legal grounds to process this information. Basic banking services fall under contractual necessity, while fraud detection is required by law. Marketing activities need explicit customer consent. The key is being transparent with customers about what information you process and why.

  Start by collecting only what you need for each specific purpose. Store information securely and give customers clear control through privacy settings. This approach builds trust while helping meet privacy requirements under the GDPR’s data minimisation principle.

  What is zero-party data ?

  

  Zero-party data emerges when customers actively share information about their financial goals and preferences. Unlike first-party data, which comes from observing customer behaviour, zero-party data comes through direct communication. Customers might share their retirement plans, communication preferences, or feedback about services.

  Interactive tools create natural opportunities for this exchange. A retirement calculator helps customers plan their future while revealing their financial goals. Budget planners offer immediate value through personalised advice. When customers see clear benefits, they’re more likely to share their preferences.

  However, voluntary sharing doesn’t mean unrestricted use. The ICO’s guidance on purpose limitation applies even to freely shared information. Tell customers exactly how you’ll use their data, document specific reasons for collecting each piece of information, and make it simple to update or remove personal data.

  Regular reviews help ensure you still need the information customers have shared. This aligns with both GDPR requirements and customer expectations about data management. By treating voluntary information with the same care as other customer data, banks build lasting trust.

  What is second-party data ?

  

  Second-party data comes from formal partnerships between banks and trusted companies. For example, a bank might work with an insurance provider to better understand shared customers’ financial needs.

  These partnerships need careful planning to protect customer privacy. The ICO’s Data Sharing Code provides clear guidelines : both organisations must agree on what data they’ll share, how they’ll protect it, and how long they’ll keep it before any sharing begins.

  Transparency builds trust in these arrangements. Tell customers about planned data sharing before it happens. Explain what information you’ll share and how it helps provide better services.

  Regular audits help ensure both partners maintain high privacy standards. Review shared data regularly to confirm it’s still necessary and properly protected. Be ready to adjust or end partnerships if privacy standards slip. Remember that your responsibility to protect customer data extends to information shared with partners.

  Successful partnerships balance improved service with diligent privacy protection. When done right, they help banks understand customer needs better while maintaining the trust that makes banking relationships work.

  What is third-party data ?

  

  Third-party data comes from external sources outside your bank and its partners. Market research firms, data analytics companies, and economic research organizations gather and sell this information to help banks understand broader market trends.

  This data helps fill knowledge gaps about the wider financial landscape. For example, third-party data might reveal shifts in consumer spending patterns across different age groups or regions. It can show how customers interact with different financial services or highlight emerging banking preferences in specific demographics.

  But third-party data needs careful evaluation before use. Since your bank didn’t collect this information directly, you must verify both its quality and compliance with privacy laws. Start by checking how providers collected their data and whether they had proper consent. Look for providers who clearly document their data sources and collection methods.

  Quality varies significantly among third-party data providers. Some key questions to consider before purchasing :

  • How recent is the data ?
  • How was it collected ?
  • What privacy protections are in place ?
  • How often is it updated ?
  • Which specific market segments does it cover ?

  Consider whether third-party data will truly add value beyond your existing information. Many banks find they can gain similar insights by analysing their first-party data more effectively. If you do use third-party data, document your reasons for using it and be transparent about your data sources.

  Creating your banking data strategy

  

  A clear data strategy helps your bank collect and use information effectively while protecting customer privacy. This matters most with first-party data – the information that comes directly from your customers’ banking activities.

  Start by understanding what data you already have. Many banks collect valuable information through everyday transactions, website visits, and customer service interactions. Review these existing data sources before adding new ones. Often, you already have the insights you need – they just need better organization.

  Map each type of data to a specific purpose. For example, transaction data might help detect fraud and improve service recommendations. Website analytics could reveal which banking features customers use most. Each data point should serve a clear business purpose while respecting customer privacy.

  Strong data quality standards support better decisions. Create processes to update customer information regularly and remove outdated records. Check data accuracy often and maintain consistent formats across your systems. These practices help ensure your insights reflect reality.

  Remember that strategy means choosing what not to do. You don’t need to collect every piece of data possible. Focus on information that helps you serve customers better while maintaining their privacy.

  Managing multiple data sources

  

  Banks work with many types of data – from direct customer interactions to market research. Each source serves a specific purpose, but combining them effectively requires careful planning and precise attention to regulations like GDPR and ePrivacy.

  First-party data forms your foundation. It shows how your customers actually use your services and what they need from their bank. This direct interaction data proves most valuable because it reflects real behaviour rather than assumptions. When customers check their balances, transfer money, or apply for loans, they show you exactly how they use banking services.

  Zero-party data adds context to these interactions. When customers share their financial goals or preferences directly, they help you understand the “why” behind their actions. This insight helps shape better services. For example, knowing a customer plans to buy a house helps you offer relevant savings tools or mortgage information at the right time.

  Second-party partnerships can fill specific knowledge gaps. Working with trusted partners might reveal how customers manage their broader financial lives. But only pursue partnerships when they offer clear value to customers. Always explain these relationships clearly and protect shared information carefully.

  Third-party data helps provide market context, but use it selectively. External market research can highlight broader trends or opportunities. However, this data often proves less reliable than information from direct customer interactions. Consider it a supplement to, not a replacement for, your own customer insights.

  Keep these principles in mind when combining data sources :

  • Prioritize direct customer interactions
  • Focus on information that improves services
  • Maintain consistent privacy standards across sources
  • Document where each insight comes from
  • Review regularly whether each source adds value
  • Work with privacy and data experts to ensure customer information is handled properly

  Enhance your web analytics strategy with Matomo

  

  The financial sector finds powerful and compliant web analytics increasingly valuable as it navigates data management and privacy regulations. Matomo provides a configurable privacy-centric solution that meets the requirements of banks and financial institutions.

  Matomo empowers your organisation to :

  • Collect accurate, GDPR-compliant web data
  • Integrate web analytics with your existing tools and platforms
  • Maintain full control over your analytics data
  • Gain insights without compromising user privacy

  Matomo is trusted by some of the world’s biggest banks and financial institutions. Try Matomo for free for 30 days to see how privacy-focused analytics can get you the insights you need while maintaining compliance and user trust.

• 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.

• Is async.js needed to process multiple ffmpeg conversions at the same time ?

  15 février 2019, par jurelik

  I’m trying to convert youtube videos to mp3 via my Node.js server, using ’ytdl-core’ and ’fluent-ffmpeg’. Since the server is intended to process multiple requests at the same time, it got me thinking whether or not async.js is needed to convert videos in a time efficient manner.

  The interesting thing however, is that upon testing the handling of multiple requests with and without using async.js, the result seems to be the same both ways - the time it takes to convert 3 videos is the same.

  Here is the code I’m using without async.js :

  server.get('/download/:id', (req, res) => {
  
  
  
    const id = req.params.id;
  
    let stream = ytdl(`https://www.youtube.com/watch?v=${id}`);
  
  
  
    ffmpeg(stream)
  
      .audioCodec('libmp3lame')
  
      .audioBitrate(128)
  
      .toFormat('mp3')
  
      .save(`public/downloads/${id}.mp3`)
  
      .on('error', err => {
  
        console.log(err);
  
      })
  
      .on('end', () => {
  
        console.log('file downloaded');
  
        send(req, `public/downloads/${id}.mp3`).pipe(res);
  
      });
  
  });

  And this is the code using async.js :

  let queue = async.queue((task, callback) => {
  
    let stream = ytdl(`https://www.youtube.com/watch?v=${task.id}`);
  
  
  
    ffmpeg(stream)
  
    .audioCodec('libmp3lame')
  
    .audioBitrate(128)
  
    .toFormat('mp3')
  
    .save(`public/downloads/${task.id}.mp3`)
  
    .on('error', err => {
  
      console.log(err);
  
      callback(err)
  
    })
  
    .on('end', () => {
  
      send(task.req, `public/downloads/${task.id}.mp3`).pipe(task.res);
  
      callback('file sucessfully downloaded');
  
    });
  
  }, 5);
  
  
  
  queue.drain = function() {
  
    console.log('all items downloaded');
  
  }
  
  
  
  server.get('/download/:id', (req, res) => {
  
    queue.push({req: req, id: req.params.id, res: res}, err => {
  
      console.log(err);
  
    });
  
  });

  Does anyone have any ideas why both methods seem to finish conversion at roughly the same time ? I would imagine using async.js should finish converting the videos faster due to processing in parallel, but that isn’t the case.

  Any thoughts would be much appreciated !