> ## Documentation Index > Fetch the complete documentation index at: https://docs.waycore.com/llms.txt > Use this file to discover all available pages before exploring further. # Core concepts > Waycore is built around a small set of structural primitives.\ > If you understand these, you understand the system. *** ## Delegated User A **delegated user** is a bank-native login created by your customer inside their commercial bank. This is **functionally identical to hiring an outsourced treasury clerk**. Waycore operates strictly within the permissions granted by the account owner. The nomenclature can vary across banks, but you will normally see this feature appears as **user**, **sub-user,** **authorized user, portal user, operator, delegate**. It is not: * A shared credential * A consumer OAuth token It is a real user identity inside the bank’s permission model. Permissions are explicitly scoped: * Read-only access * Transfer initiation (optional) * Approval authority (optional) Waycore operates exclusively through this delegated identity. **Implication:**\ The bank controls the permission surface. Waycore does not (and cannot) bypass it. *** ## Entity An **entity** is the business that owns data and connections in the public API. It gives you a stable ownership boundary for: * Connections * Accounts * Transactions * Your own internal customer or fund mappings In practice, entities let you model customer businesses, subsidiaries, SPVs, or your own operating company in a way that stays consistent across institutions. *** ## Institution An **institution** is a bank or fintech record Waycore already recognizes in the public catalog. An institution object represents: * The bank, banking platform, or fintech * A stable `institutionId` * Default and additional portal URLs when known * A searchable discovery record you can use when one is available It does **not** represent a live connection by itself, and it is not required before onboarding starts. Banks that are not in the catalog can still be onboarded through a raw `portalUrl` on the connection create call. *** ## Connection A **connection** is the live, entity-owned integration with a bank target identified by either an `institutionId` or a bank `portalUrl`. Connections are created in stages: * `kind="setup"` while delegated-user onboarding is still in progress * `kind="ready"` once the connection is activated and able to sync The public API integrates first around this connection lifecycle, then around the accounts and transactions discovered through it. *** ## Connection Lifecycle Public connection states include: * `draft`: The connection is created, but onboarding inputs are still incomplete. * `pendingActivation`: Bank-side setup is complete and Waycore is validating and activating the connection. * `active`: Syncing normally. * `reauthRequired`: Bank authentication requires re-authentication before sync can continue. * `errored`: A recoverable issue is preventing sync. Waycore will address and retry automatically. * `invalidConfig`: Connection configuration is invalid and needs correction before normal operation can resume. * `paused`: Syncing has been intentionally suspended by the Waycore team, usually during a new version release or an active bug investigation. API read endpoints continue to work as expected during this period. * `revoked`: Access has been removed. No further syncs will occur. These states make delegated-user onboarding and ongoing bank health explicit, rather than hiding them behind a single "connected" flag. *** ## Transfer A **transfer** is a public API payment object that represents a requested movement of funds through a connected bank account. Transfers support internal account movements and external payment rails such as ACH, wire, SWIFT, FedNow, RTP, SEPA, and local rails, subject to API access, institution capabilities, and the delegated user's bank-side permissions. > **Note:** All external transfers require end-user approval in the bank portal. Waycore initiates the bank-side flow, then the end user completes approval at the bank. Internal transfer approval requirements depend on the bank, account setup, and delegated-user permissions. *** ## Webhook Event A **webhook event** is an operational signal emitted by the public API when subscribed events occur. Current public producers include: * Connection status changes * Transaction sync availability * Explicit `test` deliveries Additional event types are reserved for future public producers. Use webhooks to trigger follow-up work and monitor connection health. For transaction reconciliation, use `transactions.sync_available` as a prompt to call `GET /v1/transactions/sync`. *** ## Audit Trail Every action is written to an immutable audit log. The audit trail includes: * Timestamp * Institution * Delegated user identity * Action performed * Result * Metadata This enables: * Compliance reporting * Operational debugging * Post-facto review *** ## Human-in-the-Loop (HITL) When automation cannot proceed (e.g., hardware MFA, unexpected bank UI), the execution enters a controlled human intervention path. HITL actions: * Are permission-bound * Are logged * Emit state updates * Do not bypass policy *** ## Design Philosophy Waycore is opinionated: * Bank permissions are the root authority. * Every action is observable. * State is explicit. * Failure modes are surfaced, not hidden. * Human-in-the-loop as a fallback for banks that require it.