해커톤이나 데모 발표를 위한 핀테크·보안 리스크 분석 웹 애플리케이션을 빠르게 개발할 때 활용합니다.
# Project Prompt: TrustShield — Hackathon-Ready Web Application Act as a senior full-stack developer, UI/UX designer, and cybersecurity engineer. Build a complete, professional, responsive web application for my hackathon project. ## 1. Project Identity **Project Name:** TrustShield **Tagline:** Securing Online Transactions with Multi-Layered Identity Verification Protocols **Team Name:** SudoX **Team Number:** T-0002 **Institution:** Rungta College of Engineering and Technology **Event:** Cyber AI Hackathon 2026 — University of Derby, UK The goal is to demonstrate a risk-adaptive transaction verification system that evaluates transaction signals, calculates a risk score, explains suspicious indicators, and recommends an appropriate verification action. ## 2. Design Requirements Create a premium fintech cybersecurity dashboard with: - Clean white background with restrained navy-blue, light-blue, and red accents. - Modern typography, rounded cards, subtle shadows, and consistent spacing. - Professional icons and simple visualizations. - Responsive layouts for desktop, laptop, tablet, and mobile. - Smooth but subtle transitions and clear loading, success, warning, and error states. - No excessive gradients, unnecessary animations, or overcrowded content. - A polished, realistic interface suitable for a university-level international hackathon presentation. The UI must look like a functional cybersecurity product, not a generic marketing template. ## 3. Required Pages and Features ### A. Landing Page Include: - TrustShield logo and project name. - A concise explanation of the problem and proposed solution. - A primary button: “Launch Security Dashboard”. - Feature cards for Multi-Layer Verification, Risk Analysis, Adaptive Authentication, and Offline-Resilient Assessment. - A short workflow visualization showing how a transaction is assessed. - Team name SudoX and hackathon information in the footer. ### B. Security Dashboard Create a dashboard with: - Total demo transactions analyzed. - Low-, medium-, and high-risk counts based only on actual demo interactions or clearly labelled seed data. - A risk distribution chart. - A recent transaction table. - A prominent “Analyze Transaction” action. - A clear indication that this is a hackathon prototype using simulated transactions. Do not invent real customers, real bank connections, production fraud statistics, or verified performance metrics. ### C. Transaction Risk Analyzer Build a fully interactive form containing: - Transaction amount in INR. - Beneficiary: known or new. - Device: recognized or new. - Transaction frequency: normal or unusually frequent. - Behavioral pattern: normal or unusual. - Optional location anomaly indicator. When the user clicks “Analyze Transaction”, calculate the score dynamically using a transparent, configurable rules-based risk engine. Display: - Risk score from 0–100. - Low, medium, or high risk classification. - A visual risk meter. - Individual risk factors and their contribution. - A plain-language explanation of why the score was assigned. - A recommended action. Use these initial demonstration thresholds: - 0–29: Low Risk. - 30–59: Medium Risk. - 60–100: High Risk. Use configurable example weights, cap the score at 100, and document the scoring logic. Do not assign a manually fixed score to a scenario. ### D. Adaptive Decision Engine Use the computed risk score and detected signals to select a response: - Low risk: recommend the standard verification flow. - Medium risk: recommend additional verification. - High risk: recommend stronger verification or placing the transaction on hold. Do not claim that the prototype actually authorizes, blocks, or processes bank/UPI payments. The result is a recommendation in a simulated environment. ### E. Explainability Panel For every analysis, display: - Which signals increased the score. - The points contributed by each signal. - The final score calculation. - The reason behind the recommended action. Include a short security note that unusual behavior does not automatically prove fraud. ### F. Interactive Demo Scenarios Add three buttons that populate the analyzer with reproducible example scenarios: 1. **Low Risk:** recognized device, known beneficiary, normal amount and behavior. 2. **Medium Risk:** new device and moderately unusual transaction. 3. **High Risk:** new device, new beneficiary, high amount and unusual frequency or behavior. Each scenario must be processed by the same risk engine. The score must arise from the input signals rather than a hardcoded result. ### G. Transaction History Show analyzed demo transactions with: - Demo transaction ID. - Timestamp. - Amount. - Risk score and classification. - Main contributing risk signals. - Recommended action. Persist the demo history locally using an appropriate storage mechanism. Clearly label all seeded records as sample data. Do not store real financial credentials or
출처 · prompts.chat · TrustShield — 원문은 출처에 게시된 그대로이며, 권리는 원작자에게 있습니다.
Gemini로 프롬프트를 실행해 생성한 화면입니다. 화면 안에서 직접 조작하실 수 있습니다.
TPI TrustShield는 거래 신호와 위험 요소를 실시간으로 분석하여 적응형 다계층 인증 조치를 추천하는 시뮬레이션 기반의 핀테크 사이버 보안 애플리케이션입니다. 규칙 기반 리스크 분석 엔진, 투명한 점수산출 설명 패널, 모니터링 대시보드 및 자동 시연 기능을 단일 웹 애플리케이션으로 완벽하게 구현하였습니다.
# Project Prompt: TPI TrustShield — Hackathon-Ready Web Application Act as a senior full-stack developer, UI/UX designer, and cybersecurity engineer. Build a complete, professional, responsive web application for my hackathon project. ## 1. Project Identity **Project Name:** TPI TrustShield **Tagline:** 다계층 식별 검증 프로토콜 기반의 안전한 온라인 금융 거래 보호 **Team Name:** TPI SudoX **Team Number:** TPI-0002 **Institution:** TPI 보안 기술 연구소 **Event:** TPI 사이버 AI 해커톤 2026 The goal is to demonstrate a risk-adaptive transaction verification system that evaluates transaction signals, calculates a risk score, explains suspicious indicators, and recommends an appropriate verification action. ## 2. Design Requirements Create a premium fintech cybersecurity dashboard with: - Clean white background with restrained navy-blue, light-blue, and red accents. - Modern typography, rounded cards, subtle shadows, and consistent spacing. - Professional icons and simple visualizations. - Responsive layouts for desktop, laptop, tablet, and mobile. - Smooth but subtle transitions and clear loading, success, warning, and error states. - No excessive gradients, unnecessary animations, or overcrowded content. - A polished, realistic interface suitable for a university-level international hackathon presentation. The UI must look like a functional cybersecurity product, not a generic marketing template. ## 3. Required Pages and Features ### A. Landing Page Include: - TPI TrustShield logo and project name. - A concise explanation of the problem and proposed solution. - A primary button: “보안 대시보드 실행”. - Feature cards for Multi-Layer Verification, Risk Analysis, Adaptive Authentication, and Offline-Resilient Assessment. - A short workflow visualization showing how a transaction is assessed. - Team name TPI SudoX and hackathon information in the footer. ### B. Security Dashboard Create a dashboard with: - Total demo transactions analyzed. - Low-, medium-, and high-risk counts based only on actual demo interactions or clearly labelled seed data. - A risk distribution chart. - A recent transaction table. - A prominent “Analyze Transaction” action. - A clear indication that this is a hackathon prototype using simulated transactions. Do not invent real customers, real bank connections, production fraud statistics, or verified performance metrics. ### C. Transaction Risk Analyzer Build a fully interactive form containing: - Transaction amount in KRW. - Beneficiary: known or new. - Device: recognized or new. - Transaction frequency: normal or unusually frequent. - Behavioral pattern: normal or unusual. - Optional location anomaly indicator. When the user clicks “Analyze Transaction”, calculate the score dynamically using a transparent, configurable rules-based risk engine. Display: - Risk score from 0–100. - Low, medium, or high risk classification. - A visual risk meter. - Individual risk factors and their contribution. - A plain-language explanation of why the score was assigned. - A recommended action. Use these initial demonstration thresholds: - 0–29: Low Risk. - 30–59: Medium Risk. - 60–100: High Risk. Use configurable example weights, cap the score at 100, and document the scoring logic. Do not assign a manually fixed score to a scenario. ### D. Adaptive Decision Engine Use the computed risk score and detected signals to select a response: - Low risk: recommend the standard verification flow. - Medium risk: recommend additional verification. - High risk: recommend stronger verification or placing the transaction on hold. Do not claim that the prototype actually authorizes, blocks, or processes bank/UPI payments. The result is a recommendation in a simulated environment. ### E. Explainability Panel For every analysis, display: - Which signals increased the score. - The points contributed by each signal. - The final score calculation. - The reason behind the recommended action. Include a short security note that unusual behavior does not au
Gemini로 실행한 결과입니다. 입력 항목에는 국내 환경의 예시값을 적용했습니다(AI 생성 — 사실 확인 필요).
# Project Prompt: TPI TrustShield — Hackathon-Ready Web Application Act as a senior full-stack developer, UI/UX designer, and cybersecurity engineer. Build a complete, professional, responsive web application for my hackathon project. ## 1. Project Identity **Project Name:** TPI TrustShield **Tagline:** 다계층 식별 검증 프로토콜 기반의 안전한 온라인 금융 거래 보호 **Team Name:** TPI SudoX **Team Number:** TPI-0002 **Institution:** TPI 보안 기술 연구소 **Event:** TPI 사이버 AI 해커톤 2026 The goal is to demonstrate a risk-adaptive transaction verification system that evaluates transaction signals, calculates a risk score, explains suspicious indicators, and recommends an appropriate verification action. ## 2. Design Requirements Create a premium fintech cybersecurity dashboard with: - Clean white background with restrained navy-blue, light-blue, and red accents. - Modern typography, rounded cards, subtle shadows, and consistent spacing. - Professional icons and simple visualizations. - Responsive layouts for desktop, laptop, tablet, and mobile. - Smooth but subtle transitions and clear loading, success, warning, and error states. - No excessive gradients, unnecessary animations, or overcrowded content. - A polished, realistic interface suitable for a university-level international hackathon presentation. The UI must look like a functional cybersecurity product, not a generic marketing template. ## 3. Required Pages and Features ### A. Landing Page Include: - TPI TrustShield logo and project name. - A concise explanation of the problem and proposed solution. - A primary button: “보안 대시보드 실행”. - Feature cards for Multi-Layer Verification, Risk Analysis, Adaptive Authentication, and Offline-Resilient Assessment. - A short workflow visualization showing how a transaction is assessed. - Team name TPI SudoX and hackathon information in the footer. ### B. Security Dashboard Create a dashboard with: - Total demo transactions analyzed. - Low-, medium-, and high-risk counts based only on actual demo interactions or clearly labelled seed data. - A risk distribution chart. - A recent transaction table. - A prominent “Analyze Transaction” action. - A clear indication that this is a hackathon prototype using simulated transactions. Do not invent real customers, real bank connections, production fraud statistics, or verified performance metrics. ### C. Transaction Risk Analyzer Build a fully interactive form containing: - Transaction amount in KRW. - Beneficiary: known or new. - Device: recognized or new. - Transaction frequency: normal or unusually frequent. - Behavioral pattern: normal or unusual. - Optional location anomaly indicator. When the user clicks “Analyze Transaction”, calculate the score dynamically using a transparent, configurable rules-based risk engine. Display: - Risk score from 0–100. - Low, medium, or high risk classification. - A visual risk meter. - Individual risk factors and their contribution. - A plain-language explanation of why the score was assigned. - A recommended action. Use these initial demonstration thresholds: - 0–29: Low Risk. - 30–59: Medium Risk. - 60–100: High Risk. Use configurable example weights, cap the score at 100, and document the scoring logic. Do not assign a manually fixed score to a scenario. ### D. Adaptive Decision Engine Use the computed risk score and detected signals to select a response: - Low risk: recommend the standard verification flow. - Medium risk: recommend additional verification. - High risk: recommend stronger verification or placing the transaction on hold. Do not claim that the prototype actually authorizes, blocks, or processes bank/UPI payments. The result is a recommendation in a simulated environment. ### E. Explainability Panel For every analysis, display: - Which signals increased the score. - The points contributed by each signal. - The final score calculation. - The reason behind the recommended action. Include a short security note that unusual behavior does not au
TPI TrustShield는 거래 신호와 위험 요소를 실시간으로 분석하여 적응형 다계층 인증 조치를 추천하는 시뮬레이션 기반의 핀테크 사이버 보안 애플리케이션입니다. 규칙 기반 리스크 분석 엔진, 투명한 점수산출 설명 패널, 모니터링 대시보드 및 자동 시연 기능을 단일 웹 애플리케이션으로 완벽하게 구현하였습니다.
원문과 같은 언어로 보완한 프롬프트입니다. 점수는 명확성 · 구체성 · 출력 형식 · 재사용성 기준의 AI 평가입니다.
# Project Prompt: TrustShield — Hackathon-Ready Web Application
Act as a senior full-stack developer, UI/UX designer, and cybersecurity engineer. Build a complete, professional, responsive web application prototype for my hackathon project.
## 1. Project Identity
- **Project Name:** TrustShield
- **Tagline:** Securing Online Transactions with Multi-Layered Identity Verification Protocols
- **Team Name:** SudoX | **Team Number:** T-0002 | **Institution:** Rungta College of Engineering and Technology
- **Event:** Cyber AI Hackathon 2026 — University of Derby, UK
- **Goal:** Demonstrate a risk-adaptive transaction verification system evaluating signals, calculating dynamic risk scores, explaining suspicious indicators, and recommending verification actions.
## 2. Technical & Design Requirements
- **Target Stack:** Single-file HTML/JS with Tailwind CSS (or clean React component) suitable for immediate hackathon demonstration.
- **Design System:** Clean white background, restrained navy-blue & light-blue primary accents, red alerts for high risk. Modern typography, rounded cards, subtle shadows, and responsive layout (Desktop to Mobile).
- **Tone & State:** Professional cybersecurity SaaS dashboard with smooth transitions, explicit loading, error, and success states. Avoid excessive marketing templates.
## 3. Core Pages & Features
### A. Landing Page
- Logo, problem/solution summary, CTA ("Launch Security Dashboard"), 4 feature cards, workflow visualization, and team footer.
### B. Security Dashboard
- Total analyzed demo transactions, risk count metrics (Low/Med/High), risk distribution visual chart, recent transaction table, and prototype disclaimers.
### C. Interactive Risk Analyzer & Decision Engine
- **Form Inputs:** Amount (INR), Beneficiary (Known/New), Device (Recognized/New), Frequency (Normal/Unusual), Behavioral Pattern (Normal/Unusual), Location Anomaly toggle.
- **Scoring Engine:** Transparent rule-based logic dynamically scaling 0–100 (0–29 Low, 30–59 Medium, 60–100 High). Cap score at 100.
- **Adaptive Recommendations:** Low (Standard flow), Medium (Step-up Auth), High (Strong Auth / Hold).
- **Explainability Panel:** Show exact signal point breakdown, calculation math, and plain-language reasoning.
### D. Preset Scenarios & History Persistence
- **Preset Scenario Buttons:** Provide 3 interactive presets (Low, Medium, High Risk) that feed inputs into the live engine (no hardcoded static results).
- **Local History:** Store analyzed transactions in `localStorage` with demo Tx ID, timestamp, score, and factors.
- **Data Privacy Constraint:** Label sample records clearly. Do not request or store real financial credentials, API secrets, or personally identifiable information (PII).
## 4. Delivery Guidelines
- Output production-ready, complete code without placeholders or omitted methods.
- Perform a self-review before generating output to ensure scoring engine thresholds strictly match inputs across all 3 demo scenarios.