Covenant AI

Covenant extraction and review for credit agreements.

Comment

CovenantAI — Our Story

What inspired us, what we learned, how we built it, and the challenges we faced.

What inspired us

We were inspired by a recurring pain in institutional lending: covenant extraction. Credit agreements routinely run to 50–200+ pages and contain dozens of financial covenants—leverage ratios like (\frac{\text{Debt}}{\text{EBITDA}}), interest coverage, lien restrictions, EBITDA definitions, and more. Legal and credit teams spend hours manually reading PDFs, copying values into spreadsheets, and tracking what’s been reviewed. One missed or mis-extracted covenant can mean compliance issues, incorrect testing, and breach risk. Banks and direct lenders do this for hundreds of agreements every year. We wanted to build something that could turn that manual, error-prone process into a structured, auditable workflow—so we built CovenantAI.

What we learned

  • Domain: We deepened our understanding of how covenants are drafted (defined terms, cross-references, add-backs) and why extraction is hard: same concepts appear in different phrasings, and values are often expressed as ratios (e.g. (4.5\text{:}1)) or ranges.
  • UX for compliance: Users need to trust the extraction. We learned that confidence scores, source-text visibility, and a clear approve/edit trail are non-negotiable for legal and credit teams.
  • Full-stack fintech: We learned how to design an API that supports async document processing, how to model covenant entities and status workflows, and how to keep the frontend responsive while the backend runs extraction jobs.
  • Document intelligence: We explored OCR, layout analysis, and LLM-based extraction—and how to combine them into a pipeline that outputs structured covenant type, value, and page reference with minimal hallucination.

How we built our project

We built CovenantAI as a full-stack application: frontend for upload, review, and export; backend for ingestion, extraction, and persistence.

Frontend (Next.js 14, TypeScript, Tailwind CSS, Framer Motion):

  • Login → Dashboard with split-view: document viewer (paginated, highlight overlays) and covenant table (type, value, page, confidence, status).
  • Upload: Drag-and-drop PDF upload; progress indicator; table updates when processing completes.
  • Audit workflow: Click a covenant row → document jumps to page and highlights the clause; audit drawer shows source paragraph with approve/edit; activity log records every action.
  • Filters & export: Search by type or value; filter by status and confidence; sort; export to CSV.

Backend:

  • API for upload, job creation, and CRUD on covenants and documents (Next.js route handlers or a separate service).
  • Document pipeline: PDF ingestion → OCR/layout analysis → text extraction → LLM/NER-based extraction of covenant type, value, and page → confidence scoring → persistence.
  • Persistence: PostgreSQL (or similar) for users, documents, covenants, and audit events; optional document store for raw PDFs and extracted text.
  • Auth: User authentication and multi-tenant awareness so teams only see their own documents and covenants.

We used a clear data model for each covenant: covenantType, extractedValue, pageReference, confidenceScore, confidenceLevel, status, sourceParagraph, and highlight (page + coordinates for the document viewer). The frontend and backend share this schema so the UI stays in sync with extraction results.

Challenges we faced

  1. Extraction accuracy: Covenant language is dense and varied. Getting consistent extraction of both type (e.g. “Debt/EBITDA”) and value (e.g. “4.5x”) across different drafting styles was hard. We tackled it with prompt engineering, structured outputs, and confidence scoring so reviewers can focus on low-confidence rows.

  2. Mapping extractions back to the document: We needed to link each extracted covenant to a specific page and region in the PDF for highlights. We combined layout analysis with character/paragraph offsets and normalized page numbering so the viewer could show the right highlight every time.

  3. Async processing and UX: Long documents take time to process. We designed the backend around async jobs and gave the frontend polling or WebSocket updates so users see a clear “Processing…” state and then a smooth transition to the populated covenant table without blocking the UI.

  4. Audit trail and compliance: Legal and compliance need a reliable record of who approved or edited what. We stored every view, approve, and edit as an event (with timestamp and user) and exposed it in the activity log and in exports, so the system is audit-ready.

  5. Scope and timeline: A full backend plus extraction pipeline is a lot for a hackathon. We prioritized end-to-end flow (upload → extract → review → export) and a clean, accessible UI, and made sure the architecture could support better models and more document types later.

Built at the Warwick Finance Societies FinTech Hackathon.

Built With

Share this project:

Updates

Submission history