Install
$ agentstack add skill-joellewis-finance-skills-data-quality ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Data Quality
Core Concepts
1. Data Quality Dimensions for Financial Data
Six dimensions define data quality. Each has domain-specific meaning in financial services.
Accuracy — Data values correctly represent the real-world entity or event they describe. A security price is accurate if it reflects the actual market closing price or evaluated value from the designated source. A client address is accurate if it matches the client's current legal address of record. Accuracy failures propagate: an inaccurate price produces inaccurate valuations, performance, billing, and regulatory reports. Accuracy is measured by comparing data against an independent authoritative source — cross-vendor price comparison, custodian-to-PMS reconciliation, client confirmation of personal data. In practice, accuracy is the hardest dimension to measure because it requires an independent reference point for comparison.
Completeness — All required data elements are present for every record. A security master record is incomplete if it lacks an ISIN, asset class classification, or pricing source designation. A client onboarding record is incomplete if beneficial ownership for entity accounts is missing. Completeness is measured as the percentage of records with all mandatory fields populated. Financial data completeness requirements are often regulatory: FinCEN requires complete beneficial ownership data, GIPS requires complete portfolio inclusion in composites, SEC Rule 17a-4 requires complete transaction records. Completeness must be defined per record type — a required field for an entity account (beneficial ownership) differs from a required field for an individual account (employment status).
Timeliness — Data is available when needed for its intended use. End-of-day pricing must arrive before the nightly valuation batch runs. Trade confirmations must be generated within SEC Rule 10b-10 timeframes. NAV calculations must complete before fund company deadlines. Timeliness is measured as the lag between event occurrence and data availability in consuming systems. Late data is functionally equivalent to missing data if it arrives after the processing window closes. Timeliness requirements vary dramatically by use case: real-time market data must arrive in milliseconds, EOD pricing within hours, and quarterly regulatory filings within weeks.
Consistency — The same fact is represented identically across all systems and time periods. A client's legal name must match across the CRM, custodian, PMS, and billing system. A security's sector classification must be the same in the portfolio management system and the compliance monitoring system. Inconsistency typically indicates either a missing golden source designation or a broken synchronization process. Consistency is measured by cross-system comparison for the same entity attribute. Temporal consistency also matters: a security's classification should not change retroactively without documented justification and downstream impact assessment.
Validity — Data conforms to defined formats, ranges, and business rules. A CUSIP must be exactly 9 characters with a valid check digit. An account registration type must be one of the firm's defined values. A bond coupon rate cannot be negative (for conventional bonds). A trade settlement date cannot precede the trade date. Validity is enforced through schema constraints, field-level validation, and business rule engines. Invalid data that passes into production indicates insufficient input validation. Validity rules should be versioned and maintained as a formal catalog — when rules change, the change should be documented with effective date and rationale.
Uniqueness — Each real-world entity is represented exactly once. A client appearing as two records in the CRM (duplicate due to name variation or data entry error) causes fragmented reporting, missed household billing discounts, and potential compliance failures (wash sale detection across accounts requires a unified client view). A security represented as two master records per custodian causes duplicated positions. Uniqueness is enforced through deduplication at ingestion and periodic duplicate detection scans. Common deduplication techniques include exact-match on identifiers (SSN, CUSIP), fuzzy matching on names and addresses (Jaro-Winkler, Levenshtein distance), and probabilistic matching combining multiple weak identifiers into a confidence score.
| Dimension | Measurement Method | Typical Target | Key Risk if Unmet | |---|---|---|---| | Accuracy | Cross-source comparison, reconciliation | >99.5% for pricing, >99% for client data | Incorrect valuations, billing, filings | | Completeness | Percentage of required fields populated | >98% for critical fields | Regulatory findings, incomplete reporting | | Timeliness | Lag from event to system availability | Within processing window | Stale valuations, missed deadlines | | Consistency | Cross-system attribute comparison | >99% agreement | Conflicting reports, audit failures | | Validity | Format and business rule pass rate | >99.9% | Processing failures, corrupt records | | Uniqueness | Duplicate detection rate | 5% variance for bonds, >15% for equities), detects stale prices (unchanged >2 business days for equities, >5 for bonds, adjusted for holidays), cross-checks Schwab and Fidelity pricing against the primary vendor, and generates a pricing exception dashboard reviewed by operations before the nightly valuation batch. For position data: daily custodian-to-PMS reconciliation with automated matching on security identifier, quantity, and market value (tolerance: 0.01% of market value), transfer detection logic that flags accounts with zero positions at one custodian and new positions at another, and position breaks categorized by severity (>$10K critical, >$1K high, 0.5% variance), account-level fee schedule validation (advisory fee within contracted range), and terminated account detection (no billing for accounts closed >30 days). Golden source designations are formalized: Schwab/Fidelity for positions and legal identity, Salesforce for relationship and suitability data, Orion for performance, and the pricing vendor for security valuations. A weekly data quality scorecard is generated and reviewed in the Monday operations meeting.
Analysis: The framework addresses all three original issues systematically. Stale bond pricing is caught by the daily pricing validation before it reaches performance calculations. Transferred-out positions are detected by the position reconciliation before billing runs. Stale suitability data is flagged by the completeness scan with sufficient lead time for advisor outreach. The ongoing cost is approximately 0.5 FTE of operations analyst time plus monitoring tool licensing. The firm targets resolution within 6 months: 99.5% pricing accuracy, 3,700), check file format integrity (header, delimiter, encoding). Layer 2 (field-level): every price must be positive numeric, currency code must be valid ISO 4217 and match the security master's expected currency, price date must equal the expected business date, identifier (CUSIP/ISIN) must exist in the security master. Layer 3 (cross-field): price-times-quantity must produce a reasonable market value per position (flag if single position >20% of fund NAV for diversified strategies), bond prices should be expressed in standard convention (percentage of par for most, dollar price for converts — validate against security type). Layer 4 (temporal): variance check against prior day — thresholds by asset class (equities 15%, investment-grade bonds 3%, high-yield 8%, structured products 10%, munis 5%), stale price detection with asset-class-specific windows (equities 2 days, liquid bonds 5 days, structured products 15 days, alternatives 45 days), and price-unchanged detection distinguished from true staleness (a money market fund NAV of 1.0000 unchanged for months is correct, not stale). Layer 5 (cross-source): secondary vendor comparison for all securities with >$1M total exposure, flag divergence exceeding thresholds (equities 2%, bonds 5%). Exception routing: critical exceptions (zero price, wrong currency, missing file, NAV-impacting variance) alert the pricing analyst immediately and block the valuation batch. High exceptions (stale prices, moderate variance) must be resolved before batch but do not trigger immediate alerts. The pricing analyst resolves exceptions via a defined hierarchy: accept primary vendor price, substitute secondary vendor price, obtain broker quote, or apply manual override (requires supervisor approval and documented rationale in the audit trail).
Analysis: The five-layer pipeline catches all three prior incident types. The discontinued structured product would be caught by stale-price detection at Layer 4. The currency mismatch would be caught at Layer 2 (currency code validation against security master). The decimal-point error would be caught at Layer 4 (variance check) and Layer 5 (cross-source comparison). The firm targets a false positive rate below 3% of the universe per night to keep the pricing analyst's workload manageable, calibrating thresholds through a 30-day baseline period before activating blocking behavior. The most important design decision is making critical exceptions block the valuation batch — this prevents bad data from reaching NAV calculations and client reports, converting a downstream client-facing error into an internal operational issue resolved before market open.
Example 3: Conducting a Data Quality Assessment for Regulatory Reporting Readiness
Scenario: A mid-size broker-dealer and RIA (dual-registered, $8B AUM, 200 employees) is preparing for a likely SEC examination. The CCO has identified regulatory reporting as a risk area: the firm files Form ADV, Form CRS, 13F filings, FOCUS reports (broker-dealer), and provides GIPS-compliant performance presentations to institutional prospects. The CCO wants a data quality assessment to identify and remediate gaps before the examination.
Design Considerations: The assessment is structured by regulatory obligation, evaluating data quality across all six dimensions for each filing's source data. Form ADV: verify AUM calculation traces to custodian position data through a documented process with reconciled inputs (accuracy, lineage), confirm client count matches the CRM with documented methodology for counting (completeness), check that fee schedules in ADV Part 2A match the billing system configuration (consistency), verify disciplinary history disclosures against FINRA BrokerCheck and firm records (accuracy). 13F filings: validate that the security universe in the filing matches all 13(f) securities held across all accounts (completeness), confirm share quantities reconcile to custodian records as of the reporting date (accuracy), verify security classification against the SEC's Official List of Section 13(f) Securities (validity), document the data flow from custodian positions through aggregation to the filed report (lineage). FOCUS reports: trace each line item to source ledger entries with documented calculation methodology (lineage, accuracy), validate net capital computation inputs against trial balance (accuracy, consistency), confirm customer reserve calculation (Rule 15c3-3) uses reconciled position and cash data (accuracy). GIPS presentations: verify composite membership lists against the firm's inclusion/exclusion criteria and document any discretion removals (completeness, validity), confirm return calculations use custodian-reconciled valuations (accuracy), validate that presentations include all required disclosures and that historical returns have not been retroactively altered except through documented error correction procedures (consistency, validity). Cross-cutting assessment: map all reporting data elements to their golden sources and document gaps in golden source designation, profile all critical reporting fields for completeness and validity, test timeliness by comparing actual data availability against filing deadlines with buffer, and verify that the firm can reproduce any previously filed report from archived source data (a common SEC examination request). Remediation is prioritized: critical findings (data that would produce incorrect filings) targeted for 30-day resolution, high findings (missing lineage documentation, incomplete golden source designations) targeted for 60 days, medium findings (process documentation gaps, monitoring enhancements) targeted for 90 days.
Analysis: The assessment transforms regulatory reporting from a periodic clerical exercise into a continuously quality-controlled process. The most common examination finding in this area is inability to reproduce filed figures — firms that cannot trace a 13F position count or ADV AUM figure back to source data face adverse findings. The assessment typically reveals that lineage documentation is the largest gap (firms produce correct reports but cannot demonstrate how), followed by completeness issues in less-frequent filings. The remediation effort is substantial (estimated 200-400 hours across compliance, operations, and technology) but materially reduces examination risk.
Common Pitfalls
- No designated golden source per data element. Without explicit golden source designation, multiple systems maintain competing versions of the same data, creating irreconcilable conflicts and no authoritative answer during disputes or examinations.
- Validating data after loading rather than before. Once invalid data enters production, it propagates to downstream systems before corrections can be applied. Validation must gate the loading process, not follow it.
- Treating data quality as a technology project rather than a business program. Technology enables quality, but governance requires business ownership, data steward accountability, and executive sponsorship. Technology-only initiatives produce tools without sustained adoption.
- Setting validation thresholds too tight or too loose. Thresholds too tight generate excessive false positives, causing alert fatigue and ignored exceptions. Thresholds too loose miss material errors. Calibrate using historical data and adjust quarterly.
- Ignoring data quality for low-frequency processes. Quarterly or annual processes (regulatory filings, tax reporting, GIPS presentations) receive less operational attention than daily processes, but their data quality failures have disproportionate regulatory and reputational impact.
- Measuring data quality without acting on measurements. Scorecards and dashboards are meaningless without defined remediation workflows, assigned owners, and accountability for improvement. Measurement without action creates a false sense of governance.
- Assuming vendor data is correct. Vendor data must be validated like any other source. Vendors have errors, coverage gaps, and delivery failures. Multi-vendor comparison is a critical quality control, not optional.
- Neglecting data lineage until a regulator asks. Constructing lineage retroactively is expensive and error-prone. Building lineage into data pipelines from inception costs a fraction of retrofitting it under examination pressure.
- Manual exception management without workflow tooling. Tracking exceptions in email or spreadsheets leads to lost exceptions, inconsistent resolution, no metrics, and no audit trail. Exception management requires purpose-built workflow with assignment, SLA tracking, and reporting.
- Confusing data quality with data quantity. Having more data sources does not improve quality — it increases complexity. Each additional source requires integration, validation, and conflict resolution. Fewer, higher-quality sources with robust validation outperform many loosely managed sources.
- Failing to version validation rules. When
…
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: JoelLewis
- Source: JoelLewis/finance_skills
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.