[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-93298":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":8,"htmlUrl":8,"language":9,"languages":8,"totalLinesOfCode":8,"stars":10,"forks":11,"watchers":12,"openIssues":13,"contributorsCount":13,"subscribersCount":13,"size":13,"stars1d":13,"stars7d":14,"stars30d":14,"stars90d":13,"forks30d":13,"starsTrendScore":15,"compositeScore":16,"rankGlobal":8,"rankLanguage":8,"license":8,"archived":17,"fork":17,"defaultBranch":18,"hasWiki":19,"hasPages":17,"topics":20,"createdAt":8,"pushedAt":8,"updatedAt":21,"readmeContent":22,"aiSummary":23,"trendingCount":13,"starSnapshotCount":13,"syncStatus":24,"lastSyncTime":25,"discoverSource":26},93298,"neobank-primitives","andry-lebedev\u002Fneobank-primitives","andry-lebedev",null,"TypeScript",156,1,106,0,50,16,59.9,false,"master",true,[],"2026-07-22 04:02:08","\u003Cdiv align=\"center\">\n\n# Neobank Primitives\n\n### Agent-native financial primitives for fintechs and software that can act.\n\nBuild accounts, identity flows, deposits, payouts, wallet transfers, and compliance-aware operations on a provider-neutral contract. Start with the working neobank demo; extend it into policy-controlled MCP tools and a TypeScript SDK.\n\n[![Live demo](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FLive_demo-Open-111111?style=for-the-badge)](https:\u002F\u002Fneobank-starter.vercel.app\u002F)\n[![TypeScript](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FTypeScript-6-3178C6?style=for-the-badge&logo=typescript&logoColor=white)](https:\u002F\u002Fwww.typescriptlang.org\u002F)\n[![React](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FReact-19-149ECA?style=for-the-badge&logo=react&logoColor=white)](https:\u002F\u002Freact.dev\u002F)\n[![Status](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FStatus-Early_build-7C5CFC?style=for-the-badge)](#project-status)\n\n[Run locally](#run-it-locally) · [Explore the primitives](#the-primitive-surface) · [See the architecture](#agent-native-architecture) · [Read the roadmap](#project-status)\n\n\u003C\u002Fdiv>\n\n![Neobank Primitives — agent-native financial infrastructure](docs\u002Fassets\u002Freadme\u002Fneobank-primitives-hero.png)\n\n## Money movement should be composable\n\nMost financial APIs expose endpoints. Autonomous software needs a safer abstraction: explicit intent, policy evaluation, normalized execution, durable state, and receipts it can reason about.\n\nNeobank Primitives is building that layer for two consumers:\n\n- **Fintech applications** that want reusable identity, account, balance, and transaction building blocks.\n- **AI agents** that need narrowly scoped financial tools, machine-readable outcomes, and human approval when policy requires it.\n\nThe repository is useful now as a fully interactive neobank starter with realistic demo data and a Swipelux sandbox integration. The MCP server, standalone SDK, policy engine, and full KYB surface described below are the direction of the project and are **not yet shipped as a production runtime**.\n\n## The primitive surface\n\n| Primitive | Working product flow | Target MCP + SDK contract |\n| --- | --- | --- |\n| **Identity** | Customer onboarding and KYC state | Create, retrieve, and monitor customer identity |\n| **Businesses** | Business account persona | Create organizations and track KYB requirements |\n| **Accounts** | Fiat accounts, stablecoin wallets, and balances | Provision and query normalized financial accounts |\n| **Transactions** | Quotes, bank payouts, and wallet transfers | Quote, authorize, execute, and inspect money movement |\n| **Storage** | Local demo ledger and provider-backed state | Persist normalized operation state, receipts, and metadata |\n| **Controls** | Human-readable execution explainers | Evaluate policies, require approval, and expose audit history |\n\nThe contract is designed to stay provider-neutral. **Swipelux is the first adapter**, not the shape every integration must inherit.\n\n## A working financial product, not a static mock\n\nDemo mode runs without credentials and remains interactive across personal and business accounts, onboarding, deposits, payouts, and wallet transfers. Turn on **How it works** to see the financial steps behind each product action.\n\n\u003Ctable>\n  \u003Ctr>\n    \u003Ctd width=\"33%\" align=\"center\">\n      \u003Cimg src=\"docs\u002Fassets\u002Freadme\u002Fbusiness-dashboard.png\" alt=\"Business account dashboard with EUR and USDC balances\" \u002F>\n      \u003Cbr \u002F>\u003Csub>\u003Cb>Business accounts\u003C\u002Fb> · fiat and stablecoin balances\u003C\u002Fsub>\n    \u003C\u002Ftd>\n    \u003Ctd width=\"33%\" align=\"center\">\n      \u003Cimg src=\"docs\u002Fassets\u002Freadme\u002Fidentity-onboarding.png\" alt=\"Identity onboarding with KYC, wallet, and bank account provisioning\" \u002F>\n      \u003Cbr \u002F>\u003Csub>\u003Cb>Identity\u003C\u002Fb> · KYC and account provisioning\u003C\u002Fsub>\n    \u003C\u002Ftd>\n    \u003Ctd width=\"33%\" align=\"center\">\n      \u003Cimg src=\"docs\u002Fassets\u002Freadme\u002Fdeposit-rails.png\" alt=\"SEPA bank transfer and USDC deposit rails\" \u002F>\n      \u003Cbr \u002F>\u003Csub>\u003Cb>Deposit rails\u003C\u002Fb> · SEPA and USDC\u003C\u002Fsub>\n    \u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n    \u003Ctd colspan=\"3\" align=\"center\">\n      \u003Cimg src=\"docs\u002Fassets\u002Freadme\u002Ftransaction-quote.png\" alt=\"Bank payout quote with fee, rate, recipient amount, and execution explainer\" \u002F>\n      \u003Cbr \u002F>\u003Csub>\u003Cb>Transaction execution\u003C\u002Fb> · quote, compliance context, conversion, and payout\u003C\u002Fsub>\n    \u003C\u002Ftd>\n  \u003C\u002Ftr>\n\u003C\u002Ftable>\n\n## Agent-native architecture\n\nAgents should not receive an unrestricted payment endpoint. They should receive constrained tools backed by the same typed SDK used by the application, with policy checks between intent and execution.\n\n```mermaid\nflowchart LR\n    A[Autonomous agent] --> M[MCP tools]\n    F[Fintech application] --> S[TypeScript SDK]\n    M --> P[Policy engine]\n    P --> S\n    S --> N[Normalized primitives]\n    N --> W[Swipelux adapter]\n    N --> X[Additional adapters]\n    W --> I[Financial infrastructure]\n    X --> I\n    P --> H[Human approval for exceptions]\n    I --> O[States, receipts, audit history]\n    O --> A\n    O --> F\n```\n\nEvery operation follows the same lifecycle:\n\n```text\nvalidate intent → evaluate policy → authorize → execute → normalize → audit\n```\n\nThe target contract treats idempotency, limits, destination rules, approvals, status, and receipts as first-class concerns—not application-specific afterthoughts.\n\n### What an agent call should look like\n\n> Target interface — illustrative, not yet part of the published runtime.\n\n```json\n{\n  \"name\": \"transactions.quote\",\n  \"arguments\": {\n    \"sourceAccountId\": \"acct_operating_eur\",\n    \"destination\": { \"type\": \"bank_recipient\", \"id\": \"rcpt_maria\" },\n    \"amount\": { \"value\": \"250.00\", \"currency\": \"EUR\" },\n    \"purpose\": \"invoice_payment\",\n    \"idempotencyKey\": \"inv_2041_quote\"\n  }\n}\n```\n\nThe tool response should give the agent enough information to make the next bounded decision:\n\n```json\n{\n  \"status\": \"approval_required\",\n  \"quoteId\": \"quote_01\",\n  \"recipientGets\": { \"value\": \"247.75\", \"currency\": \"EUR\" },\n  \"fee\": { \"value\": \"2.25\", \"currency\": \"EUR\" },\n  \"policy\": {\n    \"decision\": \"review\",\n    \"reason\": \"new_destination\"\n  },\n  \"expiresAt\": \"2026-07-13T18:30:00Z\"\n}\n```\n\n## Policy-controlled autonomy\n\nThe intended safety model is simple:\n\n1. An application or agent submits a structured financial intent.\n2. Policy validates identity state, permissions, limits, destination rules, purpose, and idempotency.\n3. Allowed operations execute automatically; exceptions pause for an authorized human.\n4. The adapter returns normalized status, provider references, receipts, and audit events.\n\nThis makes autonomy configurable instead of binary. A treasury agent might rebalance approved wallets automatically while a first-time bank recipient always requires review.\n\n## Run it locally\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Fandry-lebedev\u002Fneobank-primitives.git\ncd neobank-primitives\nnpm install\nnpm run dev\n```\n\nNo `.env` file is required for demo mode. Open the local URL, switch between personal and business personas, onboard a customer, add funds, request a payout quote, and inspect the execution story.\n\n### Connect the first adapter\n\nClick **Go live** in the app and provide a Swipelux sandbox API key. The key is held in the browser session and the same screens switch from realistic local data to the live adapter.\n\nThe existing integration lives under [`src\u002Fdata\u002Flive`](src\u002Fdata\u002Flive), behind the same `DataSource` contract used by the demo implementation. Provider documentation: [Swipelux API reference](https:\u002F\u002Fplatform.swipelux.com\u002Fapi-reference) · [Swipelux docs](https:\u002F\u002Fdocs.swipelux.com)\n\n## Project status\n\n| Area | Available now | Next |\n| --- | --- | --- |\n| Product demo | Personal + business personas, onboarding, balances, deposits, payouts, transfers, activity | More operational and approval workflows |\n| Identity | Customer onboarding and KYC product states | Full KYB primitives and requirement handling |\n| Integrations | Demo data source and Swipelux sandbox adapter | Additional provider adapters |\n| Developer surface | Typed in-app domain and `DataSource` boundary | Published TypeScript SDK |\n| Agent surface | Human-readable operation explainers | MCP server backed by the SDK |\n| Controls | Explicit demo\u002Flive modes and operation events | Policy engine, approval queue, durable receipts, audit API |\n\nThis is an early build. Do not use demo addresses for real funds, and do not treat the current UI as a production compliance or custody system. Production users remain responsible for provider onboarding, credentials, jurisdictional requirements, policy configuration, and operational controls.\n\n## Make the starter yours\n\nThe UI is intentionally easy to fork. Give the following prompt to a coding agent after cloning:\n\n```text\nRead AGENTS.md and PROMPT.md, then adapt this neobank starter to my product.\nAsk for my company name, audience, and brand direction. Work on a new branch,\nkeep financial flows and tests intact, edit the documented brand surfaces first,\nrun the quality checks, and show me the finished local app.\n```\n\nBrand-only changes are concentrated in `src\u002Ftheme.css` and `src\u002Fbrand.config.ts`. Feature extensions should preserve the domain boundary so future SDK and MCP surfaces can share the same primitives.\n\n## Quality commands\n\n```bash\nnpm test\nnpm run lint\nnpm run typecheck\nnpm run build\n```\n\n## Contributing\n\nThe most valuable contributions strengthen the primitive boundary: normalized transaction states, adapter contracts, policy decisions, approvals, receipts, KYB requirements, and deterministic demo scenarios. Open an issue before making a large architectural change so the application, SDK, and MCP direction stay aligned.\n\n---\n\n\u003Cdiv align=\"center\">\n  \u003Cb>Build financial products for humans. Expose financial primitives to agents.\u003C\u002Fb>\n\u003C\u002Fdiv>\n","Neobank Primitives 是一个面向金融科技与AI代理的金融基础能力抽象框架，提供身份、账户、交易、合规控制等可组合的金融原语（primitives）。其核心采用 provider-neutral 合约设计，支持多支付\u002F清结算服务商适配（当前集成 Swipelux 沙箱），内置策略驱动的执行流程、机器可读的操作凭证与人工审批触发机制。技术上基于 TypeScript 构建，配套 React 前端演示与 SDK 雏形，适用于构建合规敏感的嵌入式银行服务、AI 代理金融工具或可审计的自动化资金流转系统。项目当前处于早期开发阶段，已提供可交互的本地化新银行演示环境。",2,"2026-07-15 02:30:11","CREATED_QUERY"]