Skip to main content
This section answers the main questions about how Waycore works and how it fits within bank and regulatory frameworks.

​
Company & category

Waycore is outsourced treasury at the scale and flexibility of software. We combine software with a controlled service layer so teams can get reliable access to balances, transactions, statements, and payment-maker workflows across commercial banks that are hard to integrate directly. The right mental model is not “AI inside your bank accounts.” The right mental model is tech-enabled outsourced treasury with strong controls.The bank remains the sole custodian of funds, the sole processor of payment instructions, and the sole enforcer of transaction controls.
It is outsourced treasury at the scale and flexibility of software.
Waycore is not an Account Information Service Provider (AISP), Payment Initiation Service Provider (PISP), or any other category of regulated payment service provider under PSD2, the UK Payment Services Regulations 2017, or equivalent frameworks. We are not registered with the FCA, any EU national competent authority, or FinCEN, and we are not required to be.AISPs and PISPs access bank accounts through open banking APIs (the PSD2 “dedicated interface” or XS2A channel) using their own regulatory credentials. The bank does not choose to admit them. The regulator compels the bank to grant access. The AISP or PISP stands between the account holder and the bank as a licensed third party.Waycore does none of this. The end customer instructs their bank to create a dedicated delegated user inside the bank’s own corporate portal, with permissions the customer defines and the bank enforces.This is the same model that has existed in corporate banking for decades: a company appointing an external bookkeeper, treasury bureau, or accounting firm to operate its bank accounts under a limited mandate. Waycore delivers this as programmable infrastructure rather than manual labour. The regulatory character of the arrangement does not change because the operator is software-assisted rather than purely human.In PSD2 terms, Waycore falls within the exclusion for technical service providers under Article 3(j) of Directive 2015/2366 and paragraph 2(j) of Schedule 1, Part 2 of the UK Payment Services Regulations 2017. These provisions exclude from the scope of payment services any service that supports the execution of payment transactions without the provider entering into possession of the funds at any point.
No. Waycore is not a money transmitter, money services business (MSB), or any other category of regulated financial services provider under federal or state law. We are not registered with FinCEN as an MSB, we do not hold money transmitter licenses in any state, and we are not required to.Money transmission, as defined under the Bank Secrecy Act and FinCEN’s implementing regulations at 31 CFR 1010.100(ff), requires the acceptance and transmission of currency or funds, or the maintenance of control over currency or funds. State money transmitter statutes, while varying in their exact language, follow the same core principle: the regulated activity is receiving, holding, or transmitting someone else’s money.Waycore does none of this. At no point in the transaction lifecycle does Waycore receive, hold, control, or redirect customer funds. Funds never pass through any Waycore account, system, or intermediary. Every payment instruction that Waycore submits is executed by the customer’s own bank, from the customer’s own account, through the bank’s own portal, using credentials the bank itself issued to a delegated user the customer created.

​
Bank permissioning & terms of use

Yes. Waycore is designed around the permissioning model banks already use: dedicated users, unique credentials, bank-enforced permissions, and auditability. This is not an exotic concept. Bank of America explicitly says businesses can allow “trusted employees or an accountant” to manage banking tasks, with unique IDs and varying levels of access, including payment permissions. Wells Fargo says businesses can review access added for an employee, bookkeeper, or accountant. Chase supports entitling users for third-party app access and managing exactly which accounts and data are shared. HSBC also provides formal third-party access processes for business accounts.Our internal review of 240+ bank terms across the US, UK, and EU found a spectrum: some banks explicitly permit automation, many do not explicitly prohibit it, and a small minority use restrictive language. Waycore’s operating model was designed for that reality: dedicated credentials, explicit customer authority, bank-native security, and a human-in-the-loop service layer where needed.
No. Quite the opposite: the service is designed specifically to avoid the bad patterns that make banks uncomfortable. We do not ask customers to normalize shared credentials as the operating model. We use dedicated users, explicit authorization, bank-enforced permissions, and revocable access. That is materially closer to adding an authorized finance operator or accountant than to “scraping in the dark.” Banks like Bank of America, Wells Fargo, Chase, and HSBC already support versions of delegated or third-party access in exactly that spirit.
Only in the same sense that you would let your bank know you are adding an accountant, treasury operator, or other authorized party to the account. In many cases, the bank is effectively informed through the access model itself: creating a dedicated user, granting entitlements, or applying for third-party access. That is already how major banks structure shared business access.
No one can honestly promise that every bank’s portal policy or login flow will never change. That would be unserious. The stronger answer is this: the durable direction in banking is toward individualized access, entitlements, explicit consent, stronger authentication, and controlled third-party connectivity. FFIEC’s guidance is consistent with that. Chase already lets customers manage third-party app entitlements, review what data is being shared, and stop sharing later. HSBC’s open-banking materials are also built around explicit consent and authorized access. That means the durable part of the model is permissioned access with controls, not shared passwords or fragile workarounds. The exact mechanics may evolve; that is why the human-in-the-loop layer matters.
Broadly, yes. Regulators do not prohibit a company from using an authorized third party to help operate treasury workflows. In the US, FFIEC guidance explicitly discusses authentication and access for third parties, service accounts, applications, and devices, which means the regulatory focus is on access control and risk management, not on banning third-party involvement. In the UK/EU, AIS and PIS are regulated categories under PSD2, but the FCA also recognizes that there are exclusions for technical service providers that simply provide IT support. (ffiec.gov)Waycore is technology plus services, not a money transmitter, and the core model is designed so it does not depend on becoming an AISP/PISP to function.
We are in the process of finalizing outside-counsel review and written analysis. We should answer that directly, not pretend the memo already exists if it does not.
Waycore never holds funds. We operate as a delegated user under your bank’s native controls.

​
Market precedent

You would not be first in the relevant sense. Businesses already add employees, bookkeepers, accountants, and other third parties to their bank access. Banks already support formal third-party access and third-party app connectivity. And large advisory firms openly offer managed treasury services as a category.What is newer here is not the idea that someone other than the CFO touches the bank. What is newer is combining that with software, long-tail bank coverage, and controlled human supervision.
Yes. That distinction matters. Credential-sharing models typically rely on a user handing over the same credentials they use themselves, often with weak permissioning and poor auditability.Waycore’s model is based on dedicated access, scoped permissions, revocability, and explicit authority. That is much closer to how banks already expect business accounts to be operated when multiple people or systems need access.

​
Security, controls & approvals

No. We are not giving an autonomous model carte blanche inside your bank.Waycore uses software to assist with treasury operations inside the permissions you define, with a human-in-the-loop operating layer where needed. The framing should be: software-enhanced treasury operations under customer-controlled authority.
No. You define the authority model at the portal level, and it is enforced by your bank. Where payment workflows are supported, Waycore handles maker-side workflow orchestration; approval remains with the customer or other bank-authorized approver.
You do. Or whoever you have explicitly designated inside your banking approval chain.
Through dedicated credentials, bank-enforced MFA, and bank-native permissioning. The point is not to work around bank security. The point is to operate inside it.
Every session is tied to a dedicated user and a defined authority model. Access scope is explicit, actions are attributable, and approvals remain in the customer’s bank-controlled flow where applicable.
Yes. That is core to the model.Banks like Bank of America, Wells Fargo, and Chase already support user-level access control, account-level permissions, and management of linked third-party access. Chase also lets customers review what data is shared and stop sharing it.
No. At no point in the transaction lifecycle does Waycore receive, hold, control, or redirect customer funds. Funds never pass through any Waycore account, wallet, escrow, or intermediary.Every payment instruction that Waycore submits is executed by the customer’s own bank, from the customer’s own account, through the bank’s own infrastructure. Waycore’s role is limited to preparing and submitting the instruction inside the bank portal on the customer’s behalf.
Waycore processes customer data solely to provide the service. We do not sell, share, or use identifiable customer data for advertising, marketing, or model training. Our infrastructure is designed to align with SOC 2 controls and, where applicable, the GLBA Safeguards Rule.All data processing is governed by our Privacy Policy and, for EU and UK customers, a Data Processing Agreement that complies with GDPR requirements including approved transfer mechanisms for cross-border data flows.

​
Operations & Human-In-The-Loop (HITL)

This is exactly why the service includes a human-in-the-loop operating layer. If a portal changes, a human can work through the change and keep the service running while the software layer is updated.That is a feature, not a bug. It is how continuity is preserved in a messy real-world banking environment.
On the customer side, very little beyond setting up the delegated user and occasionally helping if the bank suspends or re-challenges that user. Internally, human involvement appears where needed to maintain continuity, especially around non-standard MFA or changing portal behavior.
We operate a secure company-controlled facility for the human-in-the-loop part of the service. That is part of the Waycore operating model, not some random outsourced back office.
The practical answer is that Waycore’s SLA is about continuity and responsiveness, not just a generic API uptime number.We support several refreshes per day by default and can refresh on demand in the right workflows. The reason the model works is that it does not fail open when a portal changes or an MFA flow gets messy. The exact SLA should be stated contractually per customer deployment.

​
Ready to get started?

Talk to us

Discuss your specific bank coverage requirements, get a custom quote, or learn more about the Pioneer Program.

Explore the API

Read the full API reference, explore the sandbox, and start building your integration today.