name: fraud-investigation-data-consolidator description: Investigates a suspicious transaction by gathering all related data from a BigQuery analytics dataset, consolidating it into a structured JSON format, and triggering alert workflows.

Instructions

Execute the following steps to investigate a suspicious transaction. The primary goal is to create a comprehensive data snapshot for a given transaction_id and trigger the required alerting and archiving workflows.

1. Initial Setup & Discovery

• Input: You will be given a specific transaction_id (e.g., T8492XJ3).
• First, confirm the target dataset and storage buckets exist.
  • Use google-cloud-bigquery_get_dataset_info to verify the transactions_analytics dataset is accessible.
  • Use google-cloud-storage_list_buckets to locate the archive bucket (name prefixed by mcp-fraud-investigation-archive-) and the log bucket (name prefixed by Trading_Logging-). Note their exact names.

2. Schema Exploration & Data Querying

• Discover all tables in the transactions_analytics dataset using google-cloud-bigquery_run_query on the INFORMATION_SCHEMA.TABLES view.
• For the target transaction, query data from two primary sources:
  1. live_transactions table: Get the full record for the given transaction_id. This record contains key foreign IDs (user_id, account_id, merchant_id, card_id, device_id, location_id).
  2. fraud_alerts table: Check for any existing alerts for this transaction_id.
• Using the IDs from the live_transactions record, query all related dimension tables:
  • users (by user_id)
  • accounts (by account_id)
  • merchants (by merchant_id)
  • cards (by card_id)
  • devices (by device_id)
  • locations (by location_id)
  • risk_scores (by user_id)
  • blacklist (Check if any of the IDs user_id, account_id, card_id, device_id, or merchant_id appear in the value column. Note: The blacklist table schema uses entity_id, entity_type, value).
• Find related transactions: Query the live_transactions table for all other transactions by the same user_id, excluding the target transaction_id. Order by timestamp DESC and limit results appropriately (e.g., 1000).

3. Data Consolidation & JSON Creation

• Structure the final JSON object with the following keys. Convert Python objects (like datetime, list, dict) to JSON-serializable strings (ISO format for dates, proper JSON arrays/objects).
  • live_transactions: The main transaction record.
  • fraud_alerts: The associated alert record (if any).
  • users, accounts, merchants, cards, devices, locations, risk_scores, blacklist: The related dimension data.
  • related_transactions: An array containing the other transactions for the user.
• Save the JSON file locally to the workspace using filesystem-write_file. Name the file <transaction_id>.json (e.g., T8492XJ3.json).

4. Archiving & Alerting

• Upload the JSON file to the identified archive storage bucket using google-cloud-storage_upload_file. Use the transaction_id as the blob name.
• Write a CRITICAL log entry to the identified logging bucket using google-cloud-logging_write_log.
  • Log Name: Use the full name of the log bucket (e.g., Trading_Logging-e877351c7447).
  • Severity: CRITICAL
  • Message/Payload: A JSON string with the exact structure: {"alert_type": "Fraud", "transaction_id": "<TRANSACTION_ID>", "status": "Pending_Investigation"}

Key Considerations

• Error Handling: If a query for a specific table returns no data, include an empty object {} for that key in the final JSON.
• Data Types: Pay special attention to serializing complex fields (flags, velocity_checks, etc.) from the live_transactions table from stringified JSON to proper JSON objects/arrays in the output.
• Bucket Names: The archive and log bucket names are dynamic (with unique suffixes). Always list buckets first to confirm their exact names.
• Logging: The log write must happen after successful archiving. The log entry is new and independent of any existing logs in the bucket.