Reglator / Use Cases
Bring us the decision. See what it changes.
Launching a product, expanding into another state or changing an operating model can move a US financial institution into a different federal and state regulatory position. Explore how Reglator could test those decisions before they go live.
Reglator Simulation Lab
What are you trying to do?
Choose an institution, a decision and a US environment. Reglator models the institution, introduces the proposed action and simulates how the federal and state regulatory position may change.
Institution
Choose your institution
Decision
What are you considering?
Environment
Where?
Select a decision and an environment to run a simulation.
- 01 CURRENT STATE/
- 02 ACTION/
- 03 INTERACTION/
- 04 STATE CHANGE/
- 05 DELTA/
- 06 DESIGN SPACE
Institution Model
Stablecoin / Digital Asset Infrastructure
- Stablecoin settlement
- Wallet infrastructure
- Institutional clients
Institutional relationships
Regulatory Delta
Output resolves after a simulation. Categories affected, potential consequences and the areas that require professional judgement.
Featured simulation
Should we add stablecoin settlement?
A licensed US payments company, one new settlement rail, then three further product decisions. Step through the states and watch the regulatory position move with each one.
Institution Model
US regulated payments business
- B2B payments
- Bank partner
- Digital asset settlement
Regulatory environments
US Federal + State environments
The United States is a network of federal, state and activity-specific environments. Each action re-tests the institution against the environments it touches.
Regulatory Delta
- Activity characterisation
- Federal implications
- State licensing scope
- AML/BSA controls
One institution. One country. Many connected regulatory environments and several possible regulatory states.
Output
What a Regulatory Delta contains.
Reglator returns the categories a decision moves, how the institution’s regulatory position could change, and the areas where professional judgement remains necessary.
Activity
Potential change in regulated activities.
Permissions
Permissions or authorisations may require assessment.
Capital
Financial resource implications detected.
Governance
Governance requirements may change.
Controls
Operational and compliance controls affected.
Reporting
Additional regulatory obligations may arise.
Judgement
Specific areas require professional regulatory assessment.
Illustrative outputs. Reglator does not provide legal or regulatory advice.
Explore by decision
Expand. Build. Operate. Transact.
Most decisions with regulatory consequences fall into one of four families. Each one is a different kind of simulation.
New states, new permissions, new regulated activities, new customer classes.
Wallets, stablecoin settlement, custody, embedded finance.
Bank partner changes, regulatory changes, customer changes, operating-model changes.
Acquisitions, complex transactions and future transaction-level testing.
Explore by role
Show me how Reglator helps my role.
Decisions this role brings us
- Which states and activities should we operate in?
- Which operating model gets us there?
- What happens if we add this product?
- What regulatory consequences should we understand before committing capital?
Primary value
Better capital allocation under regulatory uncertainty.
More simulations
A product feature can become a regulatory architecture decision.
Configuration
- Current business
- US B2B payments
- Proposed feature
- Stablecoin settlement
- Environments
- US Federal + multi-state
A product feature can become a regulatory architecture decision.
Categories identified
- Activity classification
- Settlement
- Custody exposure
- Safeguarding
- Counterparty structure
- Governance
- Reporting
- Permissions
Operating configurations
- OPTION APerform settlement in-house
- OPTION BRegulated settlement counterparty
- OPTION CSplit customer-facing and settlement functions
- OPTION DRestricted settlement configuration
Bank
Can we launch the same digital product across several markets?
Institution Model
US bank
Fintech partnership: embedded payments programme
Federal environment
REVIEW
Existing authority may cover the programme; scope and supervision require confirmation.
State environment
STATE CHANGE
The programme may reach activities and customers outside the current footprint.
Activity-specific environment
CONFIGURATION DIFFERENCE
The same capability may require a different operating configuration.
The decision may be one partnership. The regulatory state it changes may not be one environment.
Embedded finance
What changes if we provide more of the regulated service ourselves?
Starting model
Technology infrastructure
Add the functions the platform performs itself and watch the regulated boundary move.
Simulated position
Regulatory exposure depends on what the institution actually does, not what it calls itself.
Multi-market fintech
Which market should we enter next?
Objective: operate the existing payments product in another state environment. The institution is simulated against each environment, then compared on qualitative states rather than scores. Illustrative only.
| Environment | Regulatory Complexity | Operating Model Change | Partner Dependency | Capital Implication | Product Modification | Judgement Required |
|---|---|---|---|---|---|---|
| New York | HIGH | HIGH | MEDIUM | HIGH | MEDIUM | HIGH |
| California | MEDIUM | MEDIUM | MEDIUM | MEDIUM | MEDIUM | MEDIUM |
| Texas | MEDIUM | MEDIUM | MEDIUM | MEDIUM | LOW | MEDIUM |
| Illinois | MEDIUM | LOW | MEDIUM | MEDIUM | LOW | MEDIUM |
Environment selection becomes a regulatory design decision before it becomes a capital allocation decision.
Product team
Can we build this feature this way?
Starting product
Payments
Add the feature under consideration while it is still a design decision.
Institution model change
No feature selected. The institution model is unchanged.
Test regulatory viability while the product is still a design decision.
COO / Compliance
Does our operating model remain valid after something changes?
Retest complete
Requires reassessment
- Partners
- Governance
- Controls
- Reporting
Unchanged in this simulation
- Entities
- Products
- Customers
- Markets
- Settlement
The institution changes. Regulation changes. Reglator retests the interaction.
Corporate development
What regulatory architecture are we actually acquiring?
A financial institution is evaluating the acquisition of a regulated fintech. Reglator models the acquirer, the target and then the proposed combined institution.
| Acquirer | Target | Post-transaction regulatory state | |
|---|---|---|---|
| Environments | Federal + three states | Nine states | Wider federal and state footprint |
| Permissions | Payments | Payments, stored value | Combined position requires assessment |
| Products | Merchant payments | Wallet, payouts | Wider product footprint |
| Customer Types | Corporate | Consumer, SME | New segments introduced |
| Regulated Activities | Payment execution | Stored value, payouts | Activity set expands |
| Dependencies | One bank partner | Two bank partners | New third-party exposure |
| Governance | Single board | Separate board | Group governance design required |
Regulatory due diligence can move from reviewing what exists to testing what the combined institution could become. Areas surfaced require professional assessment.
Investor view
See why regulatory simulation can become infrastructure.
Run the same kind of simulation across institutions, or the same institution across environments. Both directions reuse what has already been modelled.
Reusable layer
One regulatory environment
- 01
More environments
- 02
More institutions
- 03
More simulations
- 04
More validated outcomes
- 05
Better decision intelligence
By institution
Use cases by institution type
Deeper pages on the decisions each kind of US institution brings to simulation, the regulatory delta that tends to move, and what management receives.
Design partners
Your decision will be more complicated than our demo. Good.
Tell us what you are trying to launch, change or enter. We are working with design partners on real regulated decisions.
What happens next
- 01We read the decision you describe.
- 02We model the institution and the environments involved.
- 03We walk you through the simulated delta and the design options.
- 04You decide whether the configuration is worth pursuing.