Requirements Document — Anti-Social Forces Check Application
Scope
Build a web application that digitizes and partially automates Fab Forward's anti-social forces screening workflow. The application replaces the current manual Excel/email-based process with a structured, auditable system.
In Scope
- Nikkei Telecom (日経テレコン) integration for negative news searches
- Government open-data OSINT checks (官報, 金融庁, 国土交通省, 法人番号)
- Internet search engine checks (Google)
- EDINET disclosure lookup for listed companies
- Check sheet (チェックシート) workflow management
- Search results ledger (検索結果一覧表) management
- Audit trail and evidence retention
Out of Scope
- 帝国データバンク (TDB / Teikoku Databank) integration — excluded due to cost
- Paid third-party anti-social check APIs (RISK EYES, RiskAnalyze, etc.) — future consideration
- Automated article content retrieval from Nikkei Telecom (cost-sensitive; only hit counts are automated)
Functional Requirements
FR-1: Check Request Management
| ID |
Requirement |
| FR-1.1 |
Users can create a new check request by entering: company name, representative name, company address, list of officers, company type (listed/unlisted), and whether officer info is disclosed |
| FR-1.2 |
The system accepts bulk input via CSV/Excel upload for batch check requests |
| FR-1.3 |
Each check request receives a unique tracking number and timestamp |
| FR-1.4 |
Check requests follow a stateful workflow: Draft → Submitted → In Review → Awaiting FF Legal → Completed → Archived |
| FR-1.5 |
Users can attach the original check sheet document (PDF/image) to the request |
FR-2: Entity Resolution & Corporate Number Lookup
| ID |
Requirement |
| FR-2.1 |
On check request creation, the system calls the National Tax Agency 法人番号 Web-API to resolve the 13-digit corporate number from company name and address |
| FR-2.2 |
The resolved corporate number serves as the primary key linking all check results for that entity |
| FR-2.3 |
The system displays basic corporate info returned by the API (official name, address, registration date, changes) |
| FR-2.4 |
For entities that cannot be resolved (sole proprietors, foreign entities), the system generates an internal tracking ID |
FR-3: EDINET Check (Listed Companies)
| ID |
Requirement |
| FR-3.1 |
For listed companies, the system queries the EDINET API to retrieve disclosure filings |
| FR-3.2 |
The system extracts and displays officer names from annual securities reports (有価証券報告書) |
| FR-3.3 |
Extracted officer names are auto-populated into the check target list |
| FR-3.4 |
The EDINET check result (confirmed/not found) is recorded with timestamp |
| ID |
Requirement |
| FR-4.1 |
The system generates the correct Nikkei Telecom search query for each entity using the standardized ~50 negative keyword set defined in the operational procedures |
| FR-4.2 |
For each check target (company name, representative, each officer), the system generates a separate search query string ready for copy-paste or direct use |
| FR-4.3 |
The system provides a one-click link to open Nikkei Telecom's article search page |
| FR-4.4 |
Users record the search result per entity: hit count (0 or N), and whether escalation to FF Legal is needed |
| FR-4.5 |
When hit count > 0, the system automatically flags the request for FF Legal review and records the escalation timestamp |
| FR-4.6 |
FF Legal users can record their article review findings and determination directly in the system |
| FR-4.7 |
The full keyword set is configurable by admin users (add/remove/edit keywords) |
FR-5: Internet Search Engine Check
| ID |
Requirement |
| FR-5.1 |
The system generates Google search URLs using the same keyword pattern as the Nikkei Telecom search for each entity |
| FR-5.2 |
Users can launch the search in a new browser tab with one click |
| FR-5.3 |
Users record the internet search result: no negative data found / negative data found with description |
| FR-5.4 |
Optionally, the system can perform automated Google Custom Search API queries and display summary results (configurable on/off) |
FR-6: Government Open Data OSINT Checks
| ID |
Requirement |
| FR-6.1 |
官報 (Official Gazette): The system searches the Internet Official Gazette (官報) for bankruptcy notices, dissolution notices, and other legal proceedings matching the entity |
| FR-6.2 |
金融庁 (FSA): The system checks the Financial Services Agency's administrative action database and license/registration lists for the entity |
| FR-6.3 |
国土交通省 (MLIT): The system checks the Ministry of Land's negative information search system for construction/real estate industry violations |
| FR-6.4 |
All OSINT check results are automatically recorded with source, timestamp, and match details |
| FR-6.5 |
Exact matches on any government database trigger an automatic alert flag on the check request |
FR-7: Results Management & Search Results Ledger
| ID |
Requirement |
| FR-7.1 |
The system maintains a digital equivalent of the 反社チェック検索結果一覧表 with all required fields: No., search date, company name, representative, address, search results, investigation confirmation, comments |
| FR-7.2 |
Each check target row records results from both Nikkei Telecom and internet search |
| FR-7.3 |
The final determination per check request is one of: No Concerns (取引開始に懸念ない) / Escalated to FF Legal / Transaction Refused (取引謝絶) |
| FR-7.4 |
When transaction is refused, the system requires a mandatory comment documenting the rationale and evidence |
| FR-7.5 |
The results ledger is exportable to Excel/CSV format matching the existing spreadsheet layout |
| FR-7.6 |
Individual check results are exportable as PDF for audit evidence |
FR-8: Workflow & Notifications
| ID |
Requirement |
| FR-8.1 |
Role-based access: Sales (create requests), Legal (perform checks), FF Legal (review escalations), Compliance Officer (final approval on refusals) |
| FR-8.2 |
Email/in-app notifications on status transitions: submission, escalation to FF Legal, completion, refusal |
| FR-8.3 |
Dashboard showing: pending checks, in-progress checks, escalated items, recently completed |
| FR-8.4 |
Overdue check alerts when a request has been in-progress beyond a configurable threshold (default: 5 business days) |
FR-9: Ongoing Monitoring
| ID |
Requirement |
| FR-9.1 |
The system tracks check expiration dates (annual re-check required) |
| FR-9.2 |
Automated alerts when an existing counterparty's annual re-check is due |
| FR-9.3 |
Ad-hoc re-check can be triggered manually at any time |
FR-10: Data Retention & Audit
| ID |
Requirement |
| FR-10.1 |
All check data is retained for 5 years after the business relationship ends, per policy |
| FR-10.2 |
Full audit trail: who performed each action, when, and what changed |
| FR-10.3 |
Archived records are read-only but searchable |
| FR-10.4 |
System logs all external API calls with request/response metadata (excluding sensitive content) |
Non-Functional Requirements
NFR-1: Technology Stack
| ID |
Requirement |
| NFR-1.1 |
Runtime: Bun |
| NFR-1.2 |
Framework: Next.js (App Router) |
| NFR-1.3 |
Language: TypeScript (strict mode) |
| NFR-1.4 |
UI: React with server components where appropriate |
| NFR-1.5 |
Database: PostgreSQL (via Prisma ORM) |
| NFR-1.6 |
Deployment: Docker container, self-hostable |
| ID |
Requirement |
| NFR-2.1 |
Corporate number lookup response < 2 seconds |
| NFR-2.2 |
OSINT checks (all government sources combined) complete within 10 seconds per entity |
| NFR-2.3 |
Dashboard page load < 1 second |
| NFR-2.4 |
Bulk import of 50 entities completes processing within 5 minutes |
NFR-3: Security
| ID |
Requirement |
| NFR-3.1 |
All external service credentials (Nikkei Telecom, etc.) stored encrypted, never in source code |
| NFR-3.2 |
Role-based access control enforced at API level |
| NFR-3.3 |
All actions logged with authenticated user identity |
| NFR-3.4 |
HTTPS only; no PII in URL parameters |
| NFR-3.5 |
Session timeout after 30 minutes of inactivity |
NFR-4: Localization
| ID |
Requirement |
| NFR-4.1 |
Primary UI language: Japanese |
| NFR-4.2 |
All date/time displayed in JST (Asia/Tokyo) |
| NFR-4.3 |
Code comments and variable names in English |
NFR-5: Compliance
| ID |
Requirement |
| NFR-5.1 |
Scraping of government sites respects robots.txt and implements polite crawl delays |
| NFR-5.2 |
No full-text storage of copyrighted articles — only metadata (source, date, headline presence/absence) |
| NFR-5.3 |
Personal information handling complies with Japan's Act on Protection of Personal Information (個人情報保護法) |