YProvided by Your Credit Union

For digital banking & technology partners

See how MyRelay fits into your platform.

Architecture

Your digital banking experience
SSO / authenticated member context
MyRelay
Sprout | Sidecar | AllSet
Your approved API / integration layer
Core + other financial systems

Provider hosted

Your infrastructure
Your database
Your storage
Your identity
Your APIs
Your security controls
Your monitoring
Your approved AI / OCR

Deployment inside your environment does not by itself create compliance. Security and compliance are configured, tested and operated by the provider.

MyRelay modules

  • Sprout
    Save, learn, grow
  • Sidecar
    Support without surrendering control
  • AllSet
    Everything important. Organized and ready.
Member experience
SproutSidecarAllSet

Switch a module off and every member-facing reference to it is removed — navigation, dashboard, permissions and reminders.

Banking adapter

Normalized MyRelay requests
  • getMemberProfile()
  • getAccounts()
  • getTransactions()
  • getAccountSummary()
  • getBills()
  • getRetirementInformation()
  • preparePayment()
  • submitAuthorizedAction()
Provider implementation
  • Core API
  • Digital banking API
  • Middleware
  • Secure data feed
  • Other

Architecture demonstration only. This does not imply that any listed platform currently supports every method.

White-label configuration

  • Institution name
  • Platform name
  • Logo
  • Colors
  • Module names
  • Enabled features
MyRelaybecomesMemberLife
SproutbecomesYouth Goals

Provider security layer

  • Institutional authorization first

    Every request is checked against what the institution's core or entitlement system already permits for that member and session.

  • Delegated permissions can only restrict

    What a member shares with another person narrows access. It can never expand what the institution authorizes.

  • Decisions are made server-side

    The interface reflects decisions; it never makes them. Client state is treated as untrusted input.

  • Every decision is auditable

    Allow, deny and step-up outcomes are emitted as structured audit events to the partner's own sink.

  • No credentials are ever stored

    The platform receives a session from the host environment. It never holds member credentials for any institution.

  • Identifiers are redacted downstream

    Account and document identifiers are masked before they reach logs, analytics or exports.

Authorization contract
  • authorize({ session, action, resourceId })
  • audit(event)
  • redact(value)

Implemented in SecurityLayer.ts. Replace the default policy engine with your entitlement service.

This deployment
  • Server-side authorizationEnforced
  • Audit sinkconsole
  • Step-up for sensitive actionsOn
  • Identifier redactionOn
  • Idle session timeout15 min
  • Credential storageNever

These are configuration and architecture controls, not a compliance certification. Security posture is determined by the deploying institution’s own infrastructure, testing and operations.

Database configuration

Every value below lives in src/config/deployment.ts and reads from your own environment or secret store. Nothing here is owned by the platform vendor.

  • Enginepostgres
  • Hostlocalhost:5432
  • Databaserelay_platform
  • Schemarelay
  • SSL modeverify-full
  • Pool2–20
  • Encryption at restOn
  • Field-level encryptionOn
  • Data residencyUS
  • Retention2555 days
  • Migrations./db/migrations
  • Passwordenv: DB_PASSWORD
Connection
postgres://relay_app@localhost:5432/relay_platform?schema=relay&sslmode=verify-full

Credentials are resolved from your secret store at runtime — the application only reads the variable name.

Platform tables

Created by your migrations, in your schema, with your prefix. Core banking data is never copied here — it is read through the adapter at request time.

  • relay.membersMember profile and onboarding answers.
  • relay.member_relationshipsFinancial relationships the member adds themselves.
  • relay.peopleThe member's trusted people.
  • relay.permissionsDelegated, module-specific permissions per person.
  • relay.documentsDocument metadata and extracted fields (files live in storage).
  • relay.remindersRenewal and follow-up dates.
  • relay.signalsSuggested updates, plus dismissed and resolved state.
  • relay.consentsMember consent settings, versioned with timestamps.
  • relay.audit_eventsAccess decisions emitted by the security layer.

Source code delivery

Editable source code
Configuration
Adapters
Documentation
Deployment configuration
Database migrations
Security layer

No dependency on developer-hosted services, databases or AI providers. Mock services in this prototype are replaced by the provider’s own implementations.