Compliance Assessor

Classify. Comply. Invoice. Offline. ~1.15 GB RAM, Windows + Linux, zero credentials committed. 🔗 github.com/saikarun-ai/Compliance-assessor-PayPal

Comment

Inspiration

I used to receive my freelance gig payments through PayPal. It started as a simple payment gateway, and today it is one of the few wallets trusted for both domestic and international transactions globally.

But PayPal is facing serious competition from Payoneer, Wise, and similar wallets — largely because of compliance complexity and integration gaps. That is exactly where Indian freelancers, startups, and influencers get stuck: which RBI Purpose Code applies, and when is the EDF filing due?

Most people solve this by guessing, Googling, and hoping the bank accepts it. A wrong code means the payment gets held. A missed deadline means the EDPMS entry stays open and the eBRC never gets issued. There is no tool that just answers the question — so I built one.

What it does

Compliance Assessor is an airgapped LLM application that turns a plain-English description of a cross-border payment into a complete compliance decision:

For freelancers and startups:

Classifies the income into the correct RBI Purpose Code (P0802, P0807, P1006, P1007, P1401, or NON_EXPORT)

Computes the EDF filing deadline based on the code and the invoice date

Creates a PayPal Sandbox invoice with the purpose code stamped into the invoice number (P0802-2026-001) and mirrored in detail.memo

Surfaces confidence, decision path, and rationale for every classification

For influencers:

Scans live YouTube and RSS data for a given niche

Produces a trend report with sentiment, content angle, engagement statistics, and a suggested brand deal pricing band in USD

Runs the same compliance classification on sponsorship income, so the brand deal is invoiced and filed correctly

The entire flow happens on the user's laptop, with no cloud LLM API, no telemetry, and no credentials committed to the repository.

How we built it

Stack:

llama.cpp with gemma-3-1b-it-Q4_K_M — a ~900 MB GGUF model running CPU-only

Node.js 24 + Express — one runtime dependency, using built-in fetch and --env-file instead of axios and dotenv

Vanilla HTML/CSS/JS — single-page chat UI, zero build step

PayPal Invoicing API v2 — OAuth 2.0 Sandbox flow, draft invoice creation, approval link extraction

Agent Reach — yt-dlp for YouTube, mcporter for Exa, feedparser for RSS

JSON file storage with atomic write-then-rename

Architecture discipline:

The rule engine in lib/rules.js is authoritative. The 1B LLM may only agree with a code the rules already admit — it cannot invent a purpose code or a deadline. This means all six acceptance cases pass with llama.cpp switched off.

Requirements are specified to IEEE 29148 — 26 functional + 5 non-functional, each with a unique ID, an acceptance condition, and a bidirectional trace to code and to an executed test.

The public repo ships with zero credentials committed — .env is gitignored, .env.example holds only empty placeholders, and a boot-log redaction layer ensures no secret ever reaches stdout.

Verification:

6 classification acceptance cases

19 invoice checks against a byte-accurate local PayPal mock

30 end-to-end checks covering every FR and NFR

npm audit across 68 packages: 0 vulnerabilities

Challenges we ran into

  1. The 1B model is not trustworthy for compliance. Small models hallucinate. A hallucinated purpose code would poison the entire downstream chain — invoice, EDF deadline, bank filing. The solution was to make the rule engine authoritative and demote the LLM to a second opinion. The LLM can only agree, never introduce.

  2. Port 8080 was already taken. On the demo machine, Oracle TNSLSNR owned port 8080. We moved llama.cpp to 8081 and made the port an environment variable. Small problem, but it would have killed the demo.

  3. Keeping the repo public without leaking credentials. A compliance tool that leaks secrets is self-defeating. We excluded the live PayPal Sandbox credentials entirely and replaced them with a byte-accurate local mock that reproduces the OAuth, invoice, and approval-link surface. 19/19 checks pass against the mock. Anyone who adds their own credentials to .env unlocks the live flow without a single code change.

  4. Proving data integrity without a running PayPal account. The mock had to return the same JSON shape as the real Sandbox API, or the tests would prove nothing. We validated it against the published PayPal Invoicing v2 schema, including negative cases (missing fields, malformed responses).

  5. Fitting a working LLM into 4 GB of RAM. A 7B model at Q4 needs ~4.7 GB just for weights. We chose gemma-3-1b-it-Q4_K_M at ~900 MB and tuned --ctx-size 2048 to keep the KV cache under 500 MB. Measured footprint with the model up: 1.15 GB.

  6. Handling genuine ambiguity honestly. Content writing could be P1007 (advertising) or P1006 (business consulting). Instead of forcing a code and looking confident, the tool flags the case with 0.30 confidence and recommends bank confirmation. That is a design decision, not a bug.

    Accomplishments that we're proud of

    working trend engine with no cloud dependency. The influencer report pulls live YouTube and RSS data, computes engagement statistics, and produces a specific dollar-denominated brand-deal band — in under 32 seconds, entirely on the local machine.

1.15 GB total footprint. The entire stack — model, server, trend pipeline — fits in about a quarter of the RAM of the target 4 GB laptop. The trend pipeline alone measures 119 MB against a 250 MB budget.

Zero credentials committed. No PayPal secret, no API key, no cookie. The security review found 0 Critical and 0 High findings, and the code is safe to submit as-is.

A complete requirements baseline. 26 functional and 5 non-functional requirements, fully traced forward to code and backward to tests. No orphan code. No untraced requirement. Modelled on IEEE 29148.

What we learned

Small models need guardrails, not trust. A 1B model can read a sentence and propose a code. It cannot be trusted to compute a filing deadline or to detect a non-export case. The correct architecture is: rules decide, LLM agrees.

The compliance gap is real and specific. Indian freelancers and influencers genuinely do not know which RBI code applies to their income, and the wrong choice has real financial consequences. This is not a hypothetical problem.

Airgapped is a feature, not a workaround. Financial data should not be sent to a third-party API to be classified. The user's laptop is the correct place for this computation. Framing airgapped as data integrity by design changed how we approached every integration decision.

Verification discipline changes the code. Writing the requirements first and mapping each to a test forced us to design for testability. It also made us honest — when we couldn't execute a check, we labelled it PARTIAL instead of claiming success.

Public repos and secrets do not mix. A repository that ships credentials is a repository that cannot be forked safely. Excluding credentials from the public repo is not a limitation. It is the correct default.

What's next for Compliance Assessor

Near-term (before submission):

Add the GitHub Pages link for the presenter deck so judges can walk through the deck with a click

Record the demo video walkthrough covering all four live outputs (SaaS subscription, ambiguous case, non-export, influencer trend)

Submit on Devpost with the repo, live deck, and video

Post-hackathon roadmap:

PA-CB partner integration — connect to a licensed Payment Aggregator like Skydo, Xflow, or Razorpay so the settlement leg is real, not just the invoicing leg

Actual EDF filing workflow — generate a bank-ready EDF packet that the user can submit to their AD Banker in one click

Exa channel registration — currently skipped; adding an Exa API key widens the trend engine's source coverage

Reddit and Xiaohongshu channels — deferred because browser-session channels exceed the 4 GB RAM budget

Multi-currency pricing bands — the trend engine currently computes in USD; extending to EUR, GBP, and AUD for European and UK brand deals

Requirements change log — the SRS is version-numbered but not yet change-logged; adding a dated change history would close the last ISO/IEC/IEEE 29148 gap

Mobile-adjacent companion — a read-only PWA that shows EDF deadlines and upcoming filings without needing the full local stack

Rules as data, not code — externalize lib/rules.js into a signed, versioned JSON ruleset so updates do not require a new release

Longer term: The vision is a compliance layer that any Indian freelancer, startup, or influencer can run on the hardware they already own — a tool that costs nothing to run, leaks nothing to the cloud, and answers the only two questions that actually matter: which code, and by when?

Quick Links Repository: github.com/saikarun-ai/Compliance-assessor-PayPal

Live showcase: compliance-assessor.netlify.app

Presenter deck: docs/presenter/index.html (opens locally, no server needed)

Requirements baseline: docs/SRS.md — 26 FR + 5 NFR

Verification evidence: docs/REQUIREMENTS-EVALUATION.md — 55 executed checks

Security review: docs/SECURITY-REVIEW.md — 0 Critical / 0 High

License: MIT

Built with: llama.cpp · gemma-3-1b-it-Q4_K_M · Node.js · Express · PayPal Invoicing API v2 · Agent Reach · yt-dlp · feedparser · mcporter

Built With

Share this project:

Updates

Submission history