This dataset comes from the Annual Community Survey question related to residents’ feeling of safety and their perceptions about their likelihood of becoming a victim of violent or property crimes. The fear of crime refers to the fear of being a victim of crime as opposed to the actual probability of being a victim of crime. The Annual Community Survey question that relates to this dataset is: “Please indicate how often you worry about each of the following: a) Getting mugged; b) Having your home burglarized when you are not there; c) Being attacked or threatened with a weapon; d) Having your car stolen or broken into; e) Being a victim of identity theft?” Respondents are asked to rate how often they worry about being a victim on a scale of 5 to 1, where 5 means “Frequently” and 1 means “Never” (without "don't know" as an option).

This page provides details about the Worry About Being a Victim performance measure. Click on the Showcases tab for any available stories or dashboards related to this data.

The performance measure dashboard is available at 1.10 Worry About Being a Victim

Additional Information

Source: Community Attitude Survey

Contact: Wydale Holmes

Contact E-Mail: Wydale_Holmes@tempe.gov

Data Source Type: CSV

Preparation Method: Data received from vendor and entered in CSV

Publish Frequency: Annual

Publish Method: Manual

Data Dictionary

Analysis of ‘1.10 Worry About Being a Victim (summary)’ provided by Analyst-2 (analyst-2.ai), based on source dataset retrieved from https://catalog.data.gov/dataset/6910da88-3615-44d9-8ee0-9bb9c1add57e on 11 February 2022.

--- Dataset description provided by original source is as follows ---

This dataset comes from the Annual Community Survey question related to residents’ feeling of safety and their perceptions about their likelihood of becoming a victim of violent or property crimes. The fear of crime refers to the fear of being a victim of crime as opposed to the actual probability of being a victim of crime. The Annual Community Survey question that relates to this dataset is: “Please indicate how often you worry about each of the following: a) Getting mugged; b) Having your home burglarized when you are not there; c) Being attacked or threatened with a weapon; d) Having your car stolen or broken into; e) Being a victim of identity theft?” Respondents are asked to rate how often they worry about being a victim on a scale of 5 to 1, where 5 means “Frequently” and 1 means “Never” (without "don't know" as an option).

This page provides details about the Worry About Being a Victim performance measure. Click on the Showcases tab for any available stories or dashboards related to this data.

The performance measure dashboard is available at 1.10 Worry About Being a Victim

Additional Information

Source: Community Attitude Survey

Contact: Wydale Holmes

Contact E-Mail: Wydale_Holmes@tempe.gov

Data Source Type: CSV

Preparation Method: Data received from vendor and entered in CSV

Publish Frequency: Annual

Publish Method: Manual

Data Dictionary

--- Original source retains full ownership of the source dataset ---

Project: Human Recourses Analysis - Human_Resources.csv

Description:

The dataset, named "Human_Resources.csv", is a comprehensive collection of employee records from a fictional company. Each row represents an individual employee, and the columns represent various features associated with that employee.

The dataset is rich, highlighting features like 'Age', 'MonthlyIncome', 'Attrition', 'BusinessTravel', 'DailyRate', 'Department', 'EducationField', 'JobSatisfaction', and many more. The main focus is the 'Attrition' variable, which indicates whether an employee left the company or not.

Employee data were sourced from various departments, encompassing a diverse array of job roles and levels. Each employee's record provides an in-depth look into their background, job specifics, and satisfaction levels.

The dataset further includes specific indicators and parameters that were considered during employee performance assessments, offering a granular look into the complexities of each employee's experience.

For privacy reasons, certain personal details and specific identifiers have been anonymized or fictionalized. Instead of names or direct identifiers, each entry is associated with a unique 'EmployeeNumber', ensuring data privacy while retaining data integrity.

The employee records were subjected to rigorous examination, encompassing both manual assessments and automated checks. The end result of this examination, specifically whether an employee left the company or not, is clearly indicated for each record.

description: The FTC produces the Consumer Sentinel Network Data Book annually using a data set of fraud, identity theft, and other reports from consumers received by the Consumer Sentinel Network. These include reports made directly by consumers to the FTC, as well as reports received by federal, state, local, and international law enforcement agencies and other non-governmental organizations. This data set includes national statistics, as well as a state-by-state listing of top report categories in each state and a listing of metropolitan areas that generated the most complaints per capita, for calendar year 2017. (Zip archive, CSV files); abstract: The FTC produces the Consumer Sentinel Network Data Book annually using a data set of fraud, identity theft, and other reports from consumers received by the Consumer Sentinel Network. These include reports made directly by consumers to the FTC, as well as reports received by federal, state, local, and international law enforcement agencies and other non-governmental organizations. This data set includes national statistics, as well as a state-by-state listing of top report categories in each state and a listing of metropolitan areas that generated the most complaints per capita, for calendar year 2017. (Zip archive, CSV files)

This dataset provides a detailed look into transactional behavior and financial activity patterns, ideal for exploring fraud detection and anomaly identification. It contains 2,512 samples of transaction data, covering various transaction attributes, customer demographics, and usage patterns. Each entry offers comprehensive insights into transaction behavior, enabling analysis for financial security and fraud detection applications.

Key Features:

• TransactionID: Unique alphanumeric identifier for each transaction.
• AccountID: Unique identifier for each account, with multiple transactions per account.
• TransactionAmount: Monetary value of each transaction, ranging from small everyday expenses to larger purchases.
• TransactionDate: Timestamp of each transaction, capturing date and time.
• TransactionType: Categorical field indicating 'Credit' or 'Debit' transactions.
• Location: Geographic location of the transaction, represented by U.S. city names.
• DeviceID: Alphanumeric identifier for devices used to perform the transaction.
• IP Address: IPv4 address associated with the transaction, with occasional changes for some accounts.
• MerchantID: Unique identifier for merchants, showing preferred and outlier merchants for each account.
• AccountBalance: Balance in the account post-transaction, with logical correlations based on transaction type and amount.
• PreviousTransactionDate: Timestamp of the last transaction for the account, aiding in calculating transaction frequency.
• Channel: Channel through which the transaction was performed (e.g., Online, ATM, Branch).
• CustomerAge: Age of the account holder, with logical groupings based on occupation.
• CustomerOccupation: Occupation of the account holder (e.g., Doctor, Engineer, Student, Retired), reflecting income patterns.
• TransactionDuration: Duration of the transaction in seconds, varying by transaction type.
• LoginAttempts: Number of login attempts before the transaction, with higher values indicating potential anomalies.

This dataset is ideal for data scientists, financial analysts, and researchers looking to analyze transactional patterns, detect fraud, and build predictive models for financial security applications. The dataset was designed for machine learning and pattern analysis tasks and is not intended as a primary data source for academic publications.

The provided JSON file, derived from the project available at the specified Kaggle link, has been transformed into a CSV format for ease of analysis. This dataset likely encompasses credit card fraud-related information. It is structured as a tabular collection of data, with rows representing individual instances and columns containing various attributes. This dataset may include details such as transaction timestamps, transaction amounts, merchant information, and features related to fraud detection. Researchers and analysts can utilize this CSV dataset to investigate patterns, trends, and anomalies related to credit card fraud. The transformation to CSV simplifies data manipulation and exploration, facilitating data-driven insights and potentially aiding in the development of fraud detection algorithms and strategies. SOURCE https://www.kaggle.com/datasets/joebeachcapital/credit-card-fraud

This competition involves advertisement data provided by BuzzCity Pte. Ltd. BuzzCity is a global mobile advertising network that has millions of consumers around the world on mobile phones and devices. In Q1 2012, over 45 billion ad banners were delivered across the BuzzCity network consisting of more than 10,000 publisher sites which reach an average of over 300 million unique users per month. The number of smartphones active on the network has also grown significantly. Smartphones now account for more than 32% phones that are served advertisements across the BuzzCity network. The "raw" data used in this competition has two types: publisher database and click database, both provided in CSV format. The publisher database records the publisher's (aka partner's) profile and comprises several fields:

publisherid - Unique identifier of a publisher. Bankaccount - Bank account associated with a publisher (may be empty) address - Mailing address of a publisher (obfuscated; may be empty) status - Label of a publisher, which can be the following: "OK" - Publishers whom BuzzCity deems as having healthy traffic (or those who slipped their detection mechanisms) "Observation" - Publishers who may have just started their traffic or their traffic statistics deviates from system wide average. BuzzCity does not have any conclusive stand with these publishers yet "Fraud" - Publishers who are deemed as fraudulent with clear proof. Buzzcity suspends their accounts and their earnings will not be paid

On the other hand, the click database records the click traffics and has several fields:

id - Unique identifier of a particular click numericip - Public IP address of a clicker/visitor deviceua - Phone model used by a clicker/visitor publisherid - Unique identifier of a publisher adscampaignid - Unique identifier of a given advertisement campaign usercountry - Country from which the surfer is clicktime - Timestamp of a given click (in YYYY-MM-DD format) publisherchannel - Publisher's channel type, which can be the following: ad - Adult sites co - Community es - Entertainment and lifestyle gd - Glamour and dating in - Information mc - Mobile content pp - Premium portal se - Search, portal, services referredurl - URL where the ad banners were clicked (obfuscated; may be empty). More details about the HTTP Referer protocol can be found in this article. Related Publication: R. J. Oentaryo, E.-P. Lim, M. Finegold, D. Lo, F.-D. Zhu, C. Phua, E.-Y. Cheu, G.-E. Yap, K. Sim, M. N. Nguyen, K. Perera, B. Neupane, M. Faisal, Z.-Y. Aung, W. L. Woon, W. Chen, D. Patel, and D. Berrar. (2014). Detecting click fraud in online advertising: A data mining approach, Journal of Machine Learning Research, 15, 99-140.

In today's digital landscape, data transparency and compliance are paramount. Organizations across industries are striving to maintain trust and adhere to regulations governing data privacy and security. To support these efforts, we present our comprehensive Ads.txt and App-Ads.txt dataset.

Key Benefits of Our Dataset:

• Coverage: Our dataset offers a comprehensive view of the Ads.txt and App-Ads.txt files, providing valuable information about publishers, advertisers, and the relationships between them. You gain a holistic understanding of the digital advertising ecosystem.
• Multiple Data Formats: We understand that flexibility is essential. Our dataset is available in multiple formats, including .CSV, .JSON, and more. Choose the format that best suits your data processing needs.
• Global Scope: Whether your business operates in a single country or spans multiple continents, our dataset is tailored to meet your needs. It provides data from various countries, allowing you to analyze regional trends and compliance.
  • Top-Quality Data: Quality matters. Our dataset is meticulously curated and continuously updated to deliver the most accurate and reliable information. Trust in the integrity of your data for critical decision-making.
  • Seamless Integration: We've designed our dataset to seamlessly integrate with your existing systems and workflows. No disruptions—just enhanced compliance and efficiency.

The Power of Ads.txt & App-Ads.txt: Ads.txt (Authorized Digital Sellers) and App-Ads.txt (Authorized Sellers for Apps) are industry standards developed by the Interactive Advertising Bureau (IAB) to increase transparency and combat ad fraud. These files specify which companies are authorized to sell digital advertising inventory on a publisher's website or app. Understanding and maintaining these files is essential for data compliance and the prevention of unauthorized ad sales.

How Can You Benefit? - Data Compliance: Ensure that your organization adheres to industry standards and regulations by monitoring Ads.txt and App-Ads.txt files effectively. - Ad Fraud Prevention: Identify unauthorized sellers and take action to prevent ad fraud, ultimately protecting your revenue and brand reputation. - Strategic Insights: Leverage the data in these files to gain insights into your competitors, partners, and the broader digital advertising landscape. - Enhanced Decision-Making: Make data-driven decisions with confidence, armed with accurate and up-to-date information about your advertising partners. - Global Reach: If your operations span the globe, our dataset provides insights into the Ads.txt and App-Ads.txt files of publishers worldwide.

Multiple Data Formats for Your Convenience: - CSV (Comma-Separated Values): A widely used format for easy data manipulation and analysis in spreadsheets and databases. - JSON (JavaScript Object Notation): Ideal for structured data and compatibility with web applications and APIs. - Other Formats: We understand that different organizations have different preferences and requirements. Please inquire about additional format options tailored to your needs.

Data That You Can Trust:

We take data quality seriously. Our team of experts curates and updates the dataset regularly to ensure that you receive the most accurate and reliable information available. Your confidence in the data is our top priority.

Seamless Integration:

Integrate our Ads.txt and App-Ads.txt dataset effortlessly into your existing systems and processes. Our goal is to enhance your compliance efforts without causing disruptions to your workflow.

In Conclusion:

Transparency and compliance are non-negotiable in today's data-driven world. Our Ads.txt and App-Ads.txt dataset empowers you with the knowledge and tools to navigate the complexities of the digital advertising ecosystem while ensuring data compliance and integrity. Whether you're a Data Protection Officer, a data compliance professional, or a business leader, our dataset is your trusted resource for maintaining data transparency and safeguarding your organization's reputation and revenue.

Get Started Today:

Don't miss out on the opportunity to unlock the power of data transparency and compliance. Contact us today to learn more about our Ads.txt and App-Ads.txt dataset, available in multiple formats and tailored to your specific needs. Join the ranks of organizations worldwide that trust our dataset for a compliant and transparent future.

Context

We wanted to create a data-set to help us classify news articles into financial-fraud and non-fraud category. Since we couldn't find any existing data-set which would've accomplished the same, we chose to create this one from scratch. Hope this becomes useful for others who are also trying to achieve something similar.

Content

We have two csv files in this data-set. The fraud.csv file contains snippets of news articles that talks about financial frauds. The nonfraud.csv file contains snippets of news articles that talks about complementary subjects. Each file has 2500 distinct entries complied from New York Times and Times of India.

Acknowledgements

The major contributions for this data-sets were from Sayan Biswas (sayanb@sahaj.ai), Oshin Anand (oshina@sahaj.ai) and Dileep Bapat (dileepb@sahaj.ai)

Data from: Doctoral dissertation; Preprint article entitled: Managers' and physicians’ perception of palm vein technology adoption in the healthcare industry. Formats of the files associated with dataset: CSV; SAV. SPSS setup files can be used to generate native SPSS file formats such as SPSS system files and SPSS portable files. SPSS setup files generally include the following SPSS sections: DATA LIST: Assigns the name, type, decimal specification (if any), and specifies the beginning and ending column locations for each variable in the data file. Users must replace the "physical-filename" with host computer-specific input file specifications. For example, users on Windows platforms should replace "physical-filename" with "C:\06512-0001-Data.txt" for the data file named "06512-0001-Data.txt" located on the root directory "C:\". VARIABLE LABELS: Assigns descriptive labels to all variables. Variable labels and variable names may be identical for some variables. VALUE LABELS: Assigns descriptive labels to codes in the data file. Not all variables necessarily have assigned value labels. MISSING VALUES: Declares user-defined missing values. Not all variables in the data file necessarily have user-defined missing values. These values can be treated specially in data transformations, statistical calculations, and case selection. MISSING VALUE RECODE: Sets user-defined numeric missing values to missing as interpreted by the SPSS system. Only variables with user-defined missing values are included in the statements. ABSTRACT: The purpose of the article is to examine the factors that influence the adoption of palm vein technology by considering the healthcare managers’ and physicians’ perception, using the Unified Theory of Acceptance and Use of Technology theoretical foundation. A quantitative approach was used for this study through which an exploratory research design was utilized. A cross-sectional questionnaire was distributed to responders who were managers and physicians in the healthcare industry and who had previous experience with palm vein technology. The perceived factors tested for correlation with adoption were perceived usefulness, complexity, security, peer influence, and relative advantage. A Pearson product-moment correlation coefficient was used to test the correlation between the perceived factors and palm vein technology. The results showed that perceived usefulness, security, and peer influence are important factors for adoption. Study limitations included purposive sampling from a single industry (healthcare) and limited literature was available with regard to managers’ and physicians’ perception of palm vein technology adoption in the healthcare industry. Researchers could focus on an examination of the impact of mediating variables on palm vein technology adoption in future studies. The study offers managers insight into the important factors that need to be considered in adopting palm vein technology. With biometric technology becoming pervasive, the study seeks to provide managers with the insight in managing the adoption of palm vein technology. KEYWORDS: biometrics, human identification, image recognition, palm vein authentication, technology adoption, user acceptance, palm vein technology

This dataset reflects reported incidents of crime (with the exception of murders where data exists for each victim) that occurred in the City of Chicago from 2001 to present, minus the most recent seven days. Data is extracted from the Chicago Police Department's CLEAR (Citizen Law Enforcement Analysis and Reporting) system. In order to protect the privacy of crime victims, addresses are shown at the block level only and specific locations are not identified. Should you have questions about this dataset, you may contact the Research & Development Division of the Chicago Police Department at 312.745.6071 or RandD@chicagopolice.org. Disclaimer: These crimes may be based upon preliminary information supplied to the Police Department by the reporting parties that have not been verified. The preliminary crime classifications may be changed at a later date based upon additional investigation and there is always the possibility of mechanical or human error. Therefore, the Chicago Police Department does not guarantee (either expressed or implied) the accuracy, completeness, timeliness, or correct sequencing of the information and the information should not be used for comparison purposes over time. The Chicago Police Department will not be responsible for any error or omission, or for the use of, or the results obtained from the use of this information. All data visualizations on maps should be considered approximate and attempts to derive specific addresses are strictly prohibited. The Chicago Police Department is not responsible for the content of any off-site pages that are referenced by or that reference this web page other than an official City of Chicago or Chicago Police Department web page. The user specifically acknowledges that the Chicago Police Department is not responsible for any defamatory, offensive, misleading, or illegal conduct of other users, links, or third parties and that the risk of injury from the foregoing rests entirely with the user. The unauthorized use of the words "Chicago Police Department," "Chicago Police," or any colorable imitation of these words or the unauthorized use of the Chicago Police Department logo is unlawful. This web page does not, in any way, authorize such use. Data is updated daily Tuesday through Sunday. The dataset contains more than 65,000 records/rows of data and cannot be viewed in full in Microsoft Excel. Therefore, when downloading the file, select CSV from the Export menu. Open the file in an ASCII text editor, such as Wordpad, to view and search. To access a list of Chicago Police Department - Illinois Uniform Crime Reporting (IUCR) codes, go to http://data.cityofchicago.org/Public-Safety/Chicago-Police-Department-Illinois-Uniform-Crime-R/c7ck-438e

The property crime rate indicator includes both the total number of property crime incidents per year in Champaign County, and the number of property crime incidents per 100,000 people per year in Champaign County. “Property crimes” are those counted in the following categories in the Illinois State Police’s annual Crime in Illinois report: Burglary, Theft (Larceny), Motor Vehicle Theft, and Arson. Like violent crime, property crime is also a major indicator of community safety.

The property crime data spans the same time period as the violent crime data: 1996 to 2021. The total number of offenses and rate per 100,000 population are both substantially lower as of 2021 than at the beginning of the study period in 1996. 2021 actually saw the lowest number of offenses and the lowest rate per 100,000 population in the study period. There are significantly more property crime offenses in Champaign County than violent crime incidents.

This data is sourced from the Illinois State Police’s annually released Crime in Illinois: Annual Uniform Crime Report, available on the Uniform Crime Report Index Offense Explorer.

Sources: Illinois State Police. (2021). Crime in Illinois: Annual Uniform Crime Report 2021. Illinois State Police. (2020). Crime in Illinois: Annual Uniform Crime Report 2020. Illinois State Police. (2019). Crime in Illinois: Annual Uniform Crime Report 2019. Illinois State Police. (2018). Crime in Illinois: Annual Uniform Crime Report 2018. Illinois State Police. (2017). Crime in Illinois: Annual Uniform Crime Report 2017. Illinois State Police. (2018). Crime in Illinois: Annual Uniform Crime Report 2018. Illinois State Police. (2017). Crime in Illinois: Annual Uniform Crime Report 2017. Illinois State Police. (2016). Crime in Illinois: Annual Uniform Crime Report 2016. Illinois State Police. (2015). Crime in Illinois: Annual Uniform Crime Report 2015. Illinois State Police. (2014). Crime in Illinois: Annual Uniform Crime Report 2014.; Illinois State Police. (2012). Crime in Illinois: Annual Uniform Crime Report 2012.; Illinois State Police. (2011). Crime in Illinois: Annual Uniform Crime Report 2010-2011.; Illinois State Police. (2009). Crime in Illinois: Annual Uniform Crime Report 2009.; Illinois State Police. (2007). Crime in Illinois: Annual Uniform Crime Report 2007.; Illinois State Police. (2005). Crime in Illinois: Annual Uniform Crime Report 2005.; Illinois State Police. (2003). Crime in Illinois: Annual Uniform Crime Report 2003.; Illinois State Police. (2001). Crime in Illinois: Annual Uniform Crime Report 2001.; Illinois State Police. (1999). Crime in Illinois: Annual Uniform Crime Report 1999.; Illinois State Police. (1997). Crime in Illinois: Annual Uniform Crime Report 1997.

Data

We provide you with a data set in CSV format. The data set contains 2 lakhh+ record train instances and 56 thousand test instance There are 31 input features, labeled V1 to V28 and Amount .

The target variable is labeled Class.

Task

Create a Classification model to predict the target variable Class.

1. A report - A Power point presentation
2. Any custom code you used
3. Instructions for me to run your model on a separate data set

What should be in the report?

1. List of any assumptions that you made
2. Description of your methodology and solution path
3. List of algorithms and techniques you used
4. List of tools and frameworks you used
5. Results and evaluation of your models

How to evaluate the model

1. Use the F1 Score for metrics
2. Any other evaluation measure that you believe is appropriate other than Accuracy.

Below is a draft DMP–style description of your credit‐card fraud detection experiment, modeled on the antiquities example:

1. Dataset Description

Research Domain
This work resides in the domain of financial fraud detection and applied machine learning. We focus on detecting anomalous credit‐card transactions in real time to reduce financial losses and improve trust in digital payment systems.

Purpose
The goal is to train and evaluate a binary classification model that flags potentially fraudulent transactions. By publishing both the code and data splits via FAIR repositories, we enable reproducible benchmarking of fraud‐detection algorithms and support future research on anomaly detection in transaction data.

Data Sources
We used the publicly available credit‐card transaction dataset from Kaggle (original source: https://www.kaggle.com/mlg-ulb/creditcardfraud), which contains anonymized transactions made by European cardholders over two days in September 2013. The dataset includes 284 807 transactions, of which 492 are fraudulent.

Method of Dataset Preparation

1. Schema validation: Renamed columns to snake_case (e.g. transaction_amount, is_declined) so they conform to DBRepo’s requirements.

2. Data import: Uploaded the full CSV into DBRepo, assigned persistent identifiers (PIDs).

3. Splitting: Programmatically derived three subsets—training (70%), validation (15%), test (15%)—using range‐based filters on the primary key actionnr. Each subset was materialized in DBRepo and assigned its own PID for precise citation.

4. Cleaning: Converted the categorical flags (is_declined, isforeigntransaction, ishighriskcountry, isfradulent) from “Y”/“N” to 1/0 and dropped non‐feature identifiers (actionnr, merchant_id).

5. Modeling: Trained a RandomForest classifier on the training split, tuned on validation, and evaluated on the held‐out test set.

2. Technical Details

Dataset Structure

• The raw data is a single CSV with columns:

  • actionnr (integer transaction ID)

  • merchant_id (string)

  • average_amount_transaction_day (float)

  • transaction_amount (float)

  • is_declined, isforeigntransaction, ishighriskcountry, isfradulent (binary flags)

  • total_number_of_declines_day, daily_chargeback_avg_amt, sixmonth_avg_chbk_amt, sixmonth_chbk_freq (numeric features)

Naming Conventions

• All columns use lowercase snake_case.

• Subsets are named creditcard_training, creditcard_validation, creditcard_test in DBRepo.

• Files in the code repo follow a clear structure:

  ├── data/         # local copies only; raw data lives in DBRepo 
  ├── notebooks/Task.ipynb 
  ├── models/rf_model_v1.joblib 
  ├── outputs/        # confusion_matrix.png, roc_curve.png, predictions.csv 
  ├── README.md 
  ├── requirements.txt 
  └── codemeta.json 
  

Required Software

• Python 3.9+

• pandas, numpy (data handling)

• scikit-learn (modeling, metrics)

• matplotlib (visualizations)

• dbrepo‐client.py (DBRepo API)

• requests (TU WRD API)

Additional Resources

• Original dataset: https://www.kaggle.com/mlg-ulb/creditcardfraud

• Scikit-learn docs: https://scikit-learn.org/stable

• DBRepo API guide: via the starter notebook’s dbrepo_client.py template

• TU WRD REST API spec: https://test.researchdata.tuwien.ac.at/api/docs

3. Further Details

Data Limitations

• Highly imbalanced: only ~0.17% of transactions are fraudulent.

• Anonymized PCA features (V1–V28) hidden; we extended with domain features but cannot reverse engineer raw variables.

• Time‐bounded: only covers two days of transactions, may not capture seasonal patterns.

Licensing and Attribution

• Raw data: CC-0 (per Kaggle terms)

• Code & notebooks: MIT License

• Model artifacts & outputs: CC-BY 4.0

• DUWRD records include ORCID identifiers for the author.

Recommended Uses

• Benchmarking new fraud‐detection algorithms on a standard imbalanced dataset.

• Educational purposes: demonstrating model‐training pipelines, FAIR data practices.

• Extension: adding time‐series or deep‐learning models.

Known Issues

• Possible temporal leakage if date/time features not handled correctly.

• Model performance may degrade on live data due to concept drift.

• Binary flags may oversimplify nuanced transaction outcomes.

Credit Card Fraud Detection Dataset (European Cardholders, September 2013)

As a data contributor, I'm sharing this crucial dataset focused on the detection of fraudulent credit card transactions. Recognizing these illicit activities is paramount for protecting customers and the integrity of financial systems.

About the Dataset:

This dataset encompasses credit card transactions made by European cardholders during a two-day period in September 2013. It presents a real-world scenario with a significant class imbalance, where fraudulent transactions are considerably less frequent than legitimate ones. Out of a total of 284,807 transactions, only 492 are instances of fraud, representing a mere 0.172% of the entire dataset.

Content of the Data:

Due to confidentiality concerns, the majority of the input features in this dataset have undergone a Principal Component Analysis (PCA) transformation. This means the original meaning and context of features V1, V2, ..., V28 are not directly provided. However, these principal components capture the variance in the underlying transaction data.

The only features that have not been transformed by PCA are:

• Time: Numerical. Represents the number of seconds elapsed between each transaction and the very first transaction recorded in the dataset.
• Amount: Numerical. The transaction amount in Euros (€). This feature could be valuable for cost-sensitive learning approaches.

The target variable for this classification task is:

• Class: Integer. Takes the value 1 in the case of a fraudulent transaction and 0 otherwise.

Important Note on Evaluation:

Given the substantial class imbalance (far more legitimate transactions than fraudulent ones), traditional accuracy metrics based on the confusion matrix can be misleading. It is strongly recommended to evaluate models using the Area Under the Precision-Recall Curve (AUPRC), as this metric is more sensitive to the performance on the minority class (fraudulent transactions).

How to Use This Dataset:

1. Download the dataset file (likely in CSV format).
2. Load the data using libraries like Pandas.
3. Understand the class imbalance: Be aware that fraudulent transactions are rare.
4. Explore the features: Analyze the distributions of 'Time', 'Amount', and the PCA-transformed features (V1-V28).
5. Address the class imbalance: Consider using techniques like oversampling the minority class, undersampling the majority class, or using specialized algorithms designed for imbalanced datasets.
6. Build and train binary classification models to predict the 'Class' variable.
7. Evaluate your models using AUPRC to get a meaningful assessment of performance in detecting fraud.

Acknowledgements and Citation:

This dataset has been collected and analyzed through a research collaboration between Worldline and the Machine Learning Group (MLG) of ULB (Université Libre de Bruxelles).

When using this dataset in your research or projects, please cite the following works as appropriate:

• Andrea Dal Pozzolo, Olivier Caelen, Reid A. Johnson and Gianluca Bontempi. Calibrating Probability with Undersampling for Unbalanced Classification. In Symposium on Computational Intelligence and Data Mining (CIDM), IEEE, 2015.
• Dal Pozzolo, Andrea; Caelen, Olivier; Le Borgne, Yann-Ael; Waterschoot, Serge; Bontempi, Gianluca. Learned lessons in credit card fraud detection from a practitioner perspective, Expert systems with applications,41,10,4915-4928,2014, Pergamon.
• Dal Pozzolo, Andrea; Boracchi, Giacomo; Caelen, Olivier; Alippi, Cesare; Bontempi, Gianluca. Credit card fraud detection: a realistic modeling and a novel learning strategy, IEEE transactions on neural networks and learning systems,29,8,3784-3797,2018,IEEE.
• Andrea Dal Pozzolo. Adaptive Machine learning for credit card fraud detection ULB MLG PhD thesis (supervised by G. Bontempi).
• Fabrizio Carcillo, Andrea Dal Pozzolo, Yann-Aël Le Borgne, Olivier Caelen, Yannis Mazzer, Gianluca Bontempi. Scarff: a scalable framework for streaming credit card fraud detection with Spark, Information fusion,41, 182-194,2018,Elsevier.
• Fabrizio Carcillo, Yann-Aël Le Borgne, Olivier Caelen, Gianluca Bontempi. Streaming active learning strategies for real-life credit card fraud detection: assessment and visualization, International Journal of Data Science and Analytics, 5,4,285-300,2018,Springer International Publishing.
• Bertrand Lebichot, Yann-Aël Le Borgne, Liyun He, Frederic Oblé, Gianluca Bontempi Deep-Learning Domain Adaptation Techniques for Credit Cards Fraud Detection, INNSBDDL 2019: Recent Advances in Big Data and Deep Learning, pp 78-88, 2019.
• Fabrizio Carcillo, Yann-Aël Le Borgne, Olivier Caelen, Frederic Oblé, Gianluca Bontempi *Combining Unsupervised and Supervised...

CSV of St. Louis County Police Department's Part 1 UCR crime data reported to the State of Missouri for 2016. Part 1 Crimes include homicide/non-negligent manslaughter, rape, robbery, aggravated assault, burglary, larceny, motor vehicle theft, arson, and human trafficking. The file contains data for each of the precincts within St. Louis County, and all areas that the St. Louis County Police Department patrols. The file does not contain data for any municipality that the Department does not patrol.Included variables:UCRCOUNT: Coded as 1 or -1. 1 indicates a crime that was reported during the given month, and the -1 refers to any crime that was subtracted or unfounded from a previous reporting period. COMPLAINTYEAR: Year of the complaintCOMPLAINTNUM: departmental complaint numberUCR_OFFENSE: string of the UCR crimeUCR_CRIME_CODE: number code that corresponds to the UCR offenseTYPE: Person=homicide, robbery, aggravated assault, rape, and human trafficking. Property=burglary, larceny, motor vehicle theft, and arsonMONTH: The month that the crime data was submitted to the State of Missouri.YEAR: Year data was submitted to the State of MissouriDT_CALLREC: Date and time that the call for the crime was receivedD_OCCURRED: date that the crime occurredDOW_OCCURRED: day of the week that the crime occurredZONE: geographical zone where the crime occurredADDRESS: address of the crime, excluded for rapes and human trafficking casesPRECINCT: The precinct where the crime occurred (North County Precinct, Central County Precinct, Affton Southwest Precinct, South County Precinct, City of Fenton Precinct, City of Wildwood Precinct, West County Precinct, City of Jennings Precinct, MetroLink Police Unit)PREMISE: The premise of the crime (eg. residential, business, etc.)REPORTING_JURIS: The jurisdiction that reported this data to the State of Missouri (Saint Louis County Parks data is reported by Saint Louis County).FOR_JURIS: The jurisdiction the data is for. This will either be a municipality name, MetroLink, or Saint Louis County.X: Longitude. If UCRCOUNT=-1 this field is blank. Additionally, if address is redacted this field will be blank.Y: Latitude: If UCRCOUNT=-1 this field is blank. Additionally, if address is redacted this field will be blank.

CSV of St. Louis County Police Department's Part 1 UCR crime data reported to the State of Missouri for 2015. Part 1 Crimes include homicide/non-negligent manslaughter, rape, robbery, aggravated assault, burglary, larceny, motor vehicle theft, arson, and human trafficking. The file contains data for each of the precincts within St. Louis County, and all areas that the St. Louis County Police Department patrols. The file does not contain data for any municipality that the Department does not patrol.Included variables:UCRCOUNT: Coded as 1 or -1. 1 indicates a crime that was reported during the given month, and the -1 refers to any crime that was subtracted or unfounded from a previous reporting period. COMPLAINTYEAR: Year of the complaintCOMPLAINTNUM: departmental complaint numberUCR_OFFENSE: string of the UCR crimeUCR_CRIME_CODE: number code that corresponds to the UCR offenseTYPE: Person=homicide, robbery, aggravated assault, rape, and human trafficking. Property=burglary, larceny, motor vehicle theft, and arsonMONTH: The month that the crime data was submitted to the State of Missouri.YEAR: Year data was submitted to the State of MissouriDT_CALLREC: Date and time that the call for the crime was receivedD_OCCURRED: date that the crime occurredDOW_OCCURRED: day of the week that the crime occurredZONE: geographical zone where the crime occurredADDRESS: address of the crime, excluded for rapes and human trafficking casesPRECINCT: The precinct where the crime occurred (North County Precinct, Central County Precinct, Affton Southwest Precinct, South County Precinct, City of Fenton Precinct, City of Wildwood Precinct, West County Precinct, City of Jennings Precinct, MetroLink Police Unit)PREMISE: The premise of the crime (eg. residential, business, etc.)REPORTING_JURIS: The jurisdiction that reported this data to the State of Missouri (Saint Louis County Parks data is reported by Saint Louis County).FOR_JURIS: The jurisdiction the data is for. This will either be a municipality name, MetroLink, or Saint Louis County.X: Longitude. If UCRCOUNT=-1 this field is blank. Additionally, if address is redacted this field will be blank.Y: Latitude: If UCRCOUNT=-1 this field is blank. Additionally, if address is redacted this field will be blank.

CSV of St. Louis County Police Department's Part 1 UCR crime data reported to the State of Missouri for 2017. Part 1 Crimes include homicide/non-negligent manslaughter, rape, robbery, aggravated assault, burglary, larceny, motor vehicle theft, arson, and human trafficking. The file contains data for each of the precincts within St. Louis County, and all areas that the St. Louis County Police Department patrols. The file does not contain data for any municipality that the Department does not patrol.Included variables:UCRCOUNT: Coded as 1 or -1. 1 indicates a crime that was reported during the given month, and the -1 refers to any crime that was subtracted or unfounded from a previous reporting period. COMPLAINTYEAR: Year of the complaintCOMPLAINTNUM: departmental complaint numberUCR_OFFENSE: string of the UCR crimeUCR_CRIME_CODE: number code that corresponds to the UCR offenseTYPE: Person=homicide, robbery, aggravated assault, rape, and human trafficking. Property=burglary, larceny, motor vehicle theft, and arsonMONTH: The month that the crime data was submitted to the State of Missouri.YEAR: Year data was submitted to the State of MissouriDT_CALLREC: Date and time that the call for the crime was receivedD_OCCURRED: date that the crime occurredDOW_OCCURRED: day of the week that the crime occurredZONE: geographical zone where the crime occurredADDRESS: address of the crime, excluded for rapes and human trafficking casesPRECINCT: The precinct where the crime occurred (North County Precinct, Central County Precinct, Affton Southwest Precinct, South County Precinct, City of Fenton Precinct, City of Wildwood Precinct, West County Precinct, City of Jennings Precinct, MetroLink Police Unit)PREMISE: The premise of the crime (eg. residential, business, etc.)REPORTING_JURIS: The jurisdiction that reported this data to the State of Missouri (Saint Louis County Parks data is reported by Saint Louis County).FOR_JURIS: The jurisdiction the data is for. This will either be a municipality name, MetroLink, or Saint Louis County.X: Longitude. If UCRCOUNT=-1 this field is blank. Additionally, if address is redacted this field will be blank.Y: Latitude: If UCRCOUNT=-1 this field is blank. Additionally, if address is redacted this field will be blank.

CSV file detailing all fraud and irregularity investigations carried out by Surrey County Council's Internal Audit team during the period 2014-15. See Metadata tab for more details.

CSV file detailing all fraud and irregularity investigations carried out by Surrey County Council's Internal Audit team during the period 2014-15. For the purpose of these figures "fraud" is an intentional false representation, including failure to declare information or abuse of position, that is carried out to make gain, cause loss or expose another to the risk of loss. This includes cases where management authorised action has been taken including, but not limited to, disciplinary action, civil action, or criminal prosecution.

Specific data schema details can be found on the Local Government Association's (LGA) website http://schemas.opendata.esd.org.uk/SeniorEmployees.

The same information is available to download as 5 star Linked Data.

This data is published as part of Surrey's obligations for transparency, as set out in the Local Government Transparency Code 2014.

Update frequency: Annually

Review date: No later than end of the month after the year end

Temporal coverage: Apr 2014 - Mar 2015

Geographical coverage: pan-Surrey (though no spatial data published)

Data lineage:

Maintainer contact: CEO Audit Team, Policy and Performance

This dataset was created for research on blockchain anomaly and fraud detection. And donated to IEEE data port online community.https://github.com/epicprojects/blockchain-anomaly-detection Files: bitcoin_hacks_2010_2013.csv: Contains known hashes of bitcoin theft/malicious transactions from 2010-2013malicious_tx_in.csv: Contains hashes of input transactions flowing into malicious transactions.