Overview
Last updated
This document gives a high-level mental model for City SDK and how integrators should think about the stack.
Use it as the starting point for product + architecture decisions before diving into any single module.
City SDK is the builder-facing integration layer for launching a neobank with City.
City sits between your product and the underlying provider stack so you don’t have to wire together wallet infrastructure, compliance vendors, swaps, lending venues, and yield systems independently.
City is not your end-user application and it does not replace your product logic.
Your team still owns:
the user experience
customer/account/ledger models
policy, permissions, and support operations
how financial capabilities are packaged into your product
There are three layers in a typical City integration:
your product
City SDK + City-managed backend flows
upstream providers and protocols
For production, default to backend-first:
frontend collects user intent and renders UX
frontend calls your backend
backend calls City SDK clients
backend stores state, enforces policy, and processes async updates
frontend renders normalized results
Use these modules depending on the capability you are building:
wallet: wallet login, session verification, and connected-account identity
add-fund: deposit-address + supported-asset flows
swap: quote, approvals, route building, execution orchestration
lending: protocol interactions
vault: yield + managed vault interactions
portfolio: indexed portfolio + activity visibility
Most teams integrate in this sequence:
wallet + account identity
funding + money movement
swaps, lending, vaults, and portfolio features
Last updated