How We Automated Real-Time Portfolio Monitoring for 8 BDCs with n8n

In early 2026, the AI-driven selloff in software stocks erased roughly $285 billion in market cap in a single week. Salesforce down 26%. ServiceNow down 28%. Intuit down 34%.

For most investors, that's a stock market story. For Business Development Companies — firms that lend to private software companies — it's a credit quality story. And for us at Insightful Agents, it was a system design problem: how do you monitor 8 BDC portfolios across hundreds of borrowers for early warning signals, in real time, without a team of analysts?

The answer: you automate it. Here's how we built the system.

The Problem: Manual Monitoring Doesn't Scale

A BDC (Business Development Company) is a publicly traded firm that lends money to small and mid-sized private businesses. They're legally required to distribute 90%+ of their income as dividends, which is why they offer 10-12% yields. The catch: when their borrowers struggle, the dividends get cut.

We track 8 BDCs in our Occam's Investing platform. Each one files quarterly SEC reports with hundreds of pages of financial data. Monitoring them manually means:

• Reading 32+ SEC filings per year (8 BDCs × 4 quarters)
• Extracting XBRL financial data from each filing
• Calculating safety metrics (NII coverage, NAV trends, leverage ratios)
• Cross-referencing industry exposure across all 8 portfolios
• Alerting subscribers when something changes

For one person, that's a full-time job. For an n8n workflow, it's a scheduled task.

The Architecture: 4 Workflow Layers

The monitoring system runs as four interconnected n8n workflows that fire automatically. No human in the loop for routine analysis.

Layer 1: SEC Filing Monitor

An n8n workflow polls the SEC EDGAR RSS feed every 15 minutes, watching for new 10-K and 10-Q filings from our 8 tracked BDCs (MAIN, ARCC, TRIN, CSWC, OBDC, CCAP, FSK, TCPC). When a new filing drops, it triggers the ingestion pipeline immediately.

Why this matters for any monitoring system: The trigger architecture determines your response time. Polling every 15 minutes means we detect new filings within minutes of publication. For a client building, say, a vendor compliance monitor, the same pattern works — poll the data source on a schedule, trigger the analysis instantly when something changes.

Layer 2: XBRL Parser and Data Extraction

SEC filings contain XBRL-tagged financial data — essentially structured XML that encodes every number in the filing. Our 50-node n8n workflow downloads the filing, parses the XBRL into structured JSON, and extracts the specific metrics we need:

• Net Investment Income (NII) per share — the actual cash earned from the loan portfolio
• NAV per share — the book value of the portfolio
• Dividend per share — what's being paid out
• Debt-to-equity ratio — leverage level
• Non-accrual rate — percentage of loans where borrowers stopped paying interest
• Industry concentrations — parsed from each BDC's unique HTML filing structure

The hardest part: Every BDC structures its SEC filing HTML differently. ARCC uses pipe-delimited industry names in an investments detail page. OBDC uses a separate industry concentration risk table. MAIN splits across multiple sub-categories. The n8n Code node handles each BDC's unique parsing logic through a routing switch. This is the kind of messy, real-world data problem that no off-the-shelf tool handles — and exactly where custom n8n workflows earn their keep.

Layer 3: Safety Scoring Engine

Once the raw data is extracted, a scoring workflow calculates two key metrics and produces a verdict:

NII Coverage Ratio:

• > 1.1x: Dividend is comfortably covered
• 0.9x – 1.1x: Watch closely — any increase in non-accruals eats the margin
• < 0.9x: Dividend is being paid from something other than current income

NAV Trend Razor:

This is the rule that catches what NII coverage alone misses. A BDC can report strong income today while quietly destroying book value through bad underwriting. The NAV Trend Razor forces the system to flag deterioration even when the headline numbers look fine.

The scoring engine assigns one of five verdicts: VERY SAFE, SAFE, ADEQUATE, WATCH, or AT RISK.

Layer 4: Alerting and Reporting

Results are stored in Supabase and trigger three types of automated outputs:

• Immediate filing alerts — subscribers get an email within minutes of a new SEC filing being processed
• Weekly Monday Scanner — a digest of all BDC safety scores with any changes from the prior week
• NAV Razor triggers — when a BDC's NAV drops below threshold, a dedicated alert fires to all subscribers immediately

What the System Caught

When the AI selloff hit software stocks in February 2026, our system was already tracking software exposure across all 8 BDC portfolios. The data told a clear story:

• ARCC: 23.8% software and services exposure — highest in our coverage
• CCAP: 20.3% software exposure
• FSK: 16.4% — plus declining NAV and underwater book value. Quality score: 20/100 (distressed)
• MAIN: 11.0% combined across three software sub-categories — but quality score 95/100, the strongest in coverage
• CSWC: 5.3% — lowest software exposure, diversified into healthcare and consumer

The system flagged FSK and TCPC as distressed (both scoring 20/100) well before the broader market panic. It wasn't making predictions — it was reading the XBRL data that was already public but buried in hundreds of pages of SEC filings.

The system doesn't predict the future. It reads the data faster than a human can and applies scoring rules consistently. The value isn't intelligence — it's speed and consistency.

Why This Matters Beyond Investing

The BDC monitoring system is specialized, but the architecture pattern is universal. Any monitoring problem with these characteristics can be solved the same way:

1. Data arrives on a schedule or event (SEC filings, vendor reports, CRM updates, project status changes)
2. The data requires parsing and normalization (every source structures it differently)
3. Scoring rules determine whether action is needed (thresholds, trend analysis, cross-referencing)
4. Alerts need to reach the right person in real time (not in next week's meeting)

We've built the same architecture for clients in different contexts:

• A professional services firm that monitors project budget utilization across 40+ active projects — alerts fire when any project crosses 80% burn rate
• An outreach pipeline that tracks lead response times — when average response time drifts above 4 hours, the system escalates to the sales manager
• A multi-tool stack audit that checks whether API credentials across 7 services are approaching expiration — alerts at 30, 14, and 7 days

The tools change. The pattern doesn't.

Lessons from Building This System

1. Every data source is unique — plan for messiness

The hardest part of the BDC system wasn't the scoring logic. It was parsing 8 different HTML structures from SEC EDGAR. Each BDC reports industry concentrations differently. Build your workflows expecting that every source will surprise you.

2. Override rules catch what formulas miss

The NAV Trend Razor is a simple override: if NAV drops more than 5%, cap the score regardless of what other metrics say. This single rule caught deterioration that the NII coverage ratio alone would have missed. In any scoring system, build at least one hard override that can't be gamed by other inputs.

3. Run your own audit tool on your own stack

Our n8n workflow audit tool runs against this monitoring system regularly. With 50+ nodes in the XBRL parser alone, missing error handlers or dormant paths would be invisible without systematic auditing. We built the tool to solve our own problem.

4. Archived workflows are a sign of health, not waste

We went through 6 iterations of the SEC XBRL parser before arriving at the current version. Each previous version still exists in our 187-workflow n8n instance as an archived reference. A growing archive means you're iterating. A growing active workflow count without archiving means you're accumulating debt.

The Automation ROI

Without automation, monitoring 8 BDCs across quarterly filings with this level of forensic detail would require approximately 20 hours per quarter of manual analyst work — reading filings, extracting data, calculating metrics, writing alerts. That's 80 hours per year.

The n8n workflows do it in minutes. Every quarter. With no human intervention. And they catch things faster than any manual review because they trigger on the SEC filing itself, not on an analyst's schedule.

That's the math behind automation: build once, run forever, catch everything.