- Broad category that covers all uses of technology in financial services.
- Includes payments, but also things like:
- Lending/credit (e.g. Klarna, LendingClub)
- Banking tech (neobanks like Monzo, Chime)
- Wealth/investing (Robinhood, Wealthfront)
- Insurance tech (Lemonade, Hippo)
- Compliance/regtech (identity verification, KYC, AML)
- Crypto & blockchain
-
A subset of fintech, focused only on moving money between parties. Examples:
-
Card processing (Visa, Stripe)
-
Mobile wallets (Apple Pay, Google Pay)
-
Cross-border transfers (Wise, PayPal)
-
Merchant acquiring / PoS
-
💳 Payments
- Card processing (credit, debit, prepaid)
- Mobile & digital wallets (Apple Pay, Google Pay, Samsung Pay)
- Bank transfers (ACH, SEPA, SWIFT, RTP, UPI)
- Peer-to-peer payments (Venmo, Cash App, PayPal)
- Merchant acquiring & POS integration
- Cross-border & remittances
- Subscription & recurring billing
- Refunds, chargebacks, and disputes
- Payment gateways & APIs (Stripe, Adyen, Braintree, etc.)
- Tokenization & PCI compliance
- Batch (ACH–US, SEPA Credit–EU)
- Instant (Faster Payments–UK, RTP–US, UPI–India, Pix–Brazil)
- Wires (SWIFT/CHAPS/RTGS) – high value. Wallets: Apple Pay, Google Pay, PayPal, local wallets (Alipay, M-Pesa, etc.).
The consumer provides payment information (e.g., credit card details) at the point of sale (POS) or online. The merchant's system sends this information to a payment gateway, which then routes it to a payment processor. The payment processor sends a request to the issuing bank (the consumer's bank) for authorization. Once authorized, the funds are transferred from the consumer's account to the merchant's acquiring bank, and finally to the merchant's account. This can take a few business days to settle
if you already have api.domain.com, don’t nest another /api in the path. Prefer:
https://api.domain.com/v1/... ✅
not https://api.domain.com/api/v1/
Base: https://api.domain.com/v1
/v1/users, /v1/users/{userId}
/v1/teams/{teamId}/members (hierarchical when it adds clarity)
GET /v1/users
POST /v1/users
GET /v1/users/{userId}
PATCH /v1/users/{userId}
DELETE /v1/users/{userId}
GET /v1/teams
POST /v1/teams
GET /v1/teams/{teamId}/members
POST /v1/teams/{teamId}/members (add)
DELETE /v1/teams/{teamId}/members/{userId} (remove)Provide an OpenAPI spec at https://api.domain.com/openapi.json and a human docs site.
If clients need lots of joins/shape control → consider GraphQL at https://api.domain.com/graphql.
If you need bi-directional push → Webhooks (https://api.domain.com/v1/webhooks) and/or WebSockets (wss://api.domain.com/v1/events)
Tenanting (if multi-tenant): prefer headers or claims; avoid putting tenant IDs in every path unless it’s core to the resource model.
Clients authenticate with a Bearer token that already contains the tenant.
Request
GET https://api.domain.com/v1/users
Authorization: Bearer eyJhbGciOi...{
"sub": "usr_9s3...",
"tid": "tn_12f4c0a9a3", // tenant id (a.k.a. orgId, accountId)
"scope": "users:read",
"role": "member",
"exp": 1750000000
}Allow only trusted service principals (e.g., machine tokens, mTLS) to specify the tenant via a header such as Tenant-Id (or X-Tenant-Id). End-user tokens should not be allowed to override tenant by header.
Request (service principal acting for a tenant)
POST https://api.domain.com/v1/invoices
Authorization: Bearer <svc_token_with_scope tenants:write_any>
Tenant-Id: tn_12f4c0a9a3
Content-Type: application/json
{ "amount": 12900, "currency": "USD" }
for wss://api.domain.com and https://api.domain.com
Cloudflare sees only hostnames (DNS records), not protocols.
You add api.domain.com in DNS and proxy it (orange cloud)
Cloudflare automatically handles both https://api.domain.com/... and wss://api.domain.com/...
When you add a DNS record in Cloudflare, each record has a little cloud icon:
- Orange cloud ☁️ (proxied) :
- Traffic to this hostname goes through Cloudflare’s proxy network.
- Cloudflare terminates TLS (SSL), applies security features (WAF, DDoS protection, bot management), caching, and then forwards the request to your origin server.
- Works for both https:// and wss:// traffic.
- Gray cloud ☁️ (DNS only) :
- Cloudflare only provides DNS resolution.
- Traffic goes directly to your origin server, bypassing Cloudflare’s proxy.
- You don’t get Cloudflare’s SSL, WAF, or DDoS protection on this hostname
modern CDNs (Cloudflare, Fastly, Akamai, etc.) use Anycast to route traffic to their edge servers. In HTTP, status code 101 means "Switching Protocols".
- When a client (like a web browser) makes a request to a server, it can include a header called Upgrade to request a change to a different protocol.
- If the server agrees, it responds with HTTP/1.1 101 Switching Protocols and then changes the communication protocol for that connection.
- WebSockets: When a client wants to upgrade from HTTP to WebSocket, the server will respond with 101 Switching Protocols if it supports WebSockets.
- HTTP/2 upgrade: Similarly, the server might upgrade from HTTP/1.1 to HTTP/2 if both sides agree.
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgradebuild an api-first bank from scratch that handles core banking,payments and compliance system
nearly all of their functionality (accounts, payments, KYC, ledger, etc.) is exposed via APIs, allowing third parties (fintechs, platforms, apps) to integrate them deeply
- Use
https://api.domain.com - Prefer Bearer tokens (OAuth 2.0 / OIDC) over cookies for API calls.
- Lock cookies (if any) to Domain=api.domain.com and do not set them for .domain.com.
- Tight CORS (explicit origin list, no wildcards with credentials, allow only needed headers/methods).
- Add WAF, DDoS/rate limiting, separate monitoring & deployment
- Use Content Security Policy (CSP) on the web app.
- Set X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy.
Frontend: https://domain.com (static site/SPA/SSR behind CDN).
Public API: https://api.domain.com (separate stack, WAF, rate limits, independent deploys).
Auth:
Browser → API: Auth Code + PKCE (tokens stored in memory, not localStorage).
Server→API or partner clients: Client Credentials.
Tokens: Short-lived access tokens (5–15 min) + refresh via a backend or a well-audited token manager. Validate issuer, audience, alg, exp, kid.
# /etc/nginx/conf.d/api.conf
map $http_origin $cors_allow_origin {
default "";
"~^https://domain\.com$" "$http_origin";
"~^https://www\.domain\.com$" "$http_origin";
}
server {
listen 443 ssl http2;
server_name api.domain.com;
# ... TLS config ...
# Preflight
if ($request_method = OPTIONS) {
add_header Access-Control-Allow-Origin $cors_allow_origin;
add_header Access-Control-Allow-Methods "GET,POST,PUT,PATCH,DELETE";
add_header Access-Control-Allow-Headers "Authorization,Content-Type";
add_header Access-Control-Max-Age 600;
add_header Vary "Origin";
return 204;
}
# Actual responses
location / {
# your upstream/proxy_pass here
# Set CORS only when origin is allowed
if ($cors_allow_origin != "") {
add_header Access-Control-Allow-Origin $cors_allow_origin;
add_header Vary "Origin";
# Only enable credentials if you must send cookies or auth via fetch with credentials
# add_header Access-Control-Allow-Credentials "true";
}
# Security/behavioral headers for APIs
add_header X-Content-Type-Options nosniff;
add_header Referrer-Policy no-referrer;
add_header Cache-Control "no-store"; # or appropriate per-resource
add_header Content-Type "application/json; charset=utf-8";
}
}
Set a strong CSP on domain.com (affects the app, not the API): Example: only allow scripts from self and your CDN/IdP.
// Program.cs (ASP.NET Core 8+)
using Microsoft.AspNetCore.Authorization;
using Microsoft.IdentityModel.Tokens;
var builder = WebApplication.CreateBuilder(args);
builder.Services
.AddAuthentication("Bearer")
.AddJwtBearer("Bearer", options =>
{
options.Authority = "https://YOUR-IDP-ISSUER"; // ends without trailing slash for MS/Okta, with for some IdPs
options.Audience = "https://api.domain.com"; // your API identifier
options.TokenValidationParameters = new TokenValidationParameters
{
ValidateIssuer = true,
ValidIssuer = "https://YOUR-IDP-ISSUER",
ValidateAudience = true,
ValidAudience = "https://api.domain.com",
ValidateLifetime = true,
ValidateIssuerSigningKey = true,
// Restrict algs if your IdP supports it
ValidAlgorithms = new[] { "RS256", "ES256" },
// Clock skew if needed:
ClockSkew = TimeSpan.FromSeconds(60)
};
// JWKS is pulled from the OIDC metadata automatically
options.MapInboundClaims = false; // keep raw claim names (e.g., "scope")
});
builder.Services.AddAuthorization(options =>
{
options.AddPolicy("orders.read", policy =>
policy.RequireAssertion(ctx =>
{
var scope = ctx.User.FindFirst("scope")?.Value ?? "";
var scopes = scope.Split(' ', StringSplitOptions.RemoveEmptyEntries);
// Some IdPs (Azure AD) put scopes in "scp"
var scp = ctx.User.FindFirst("scp")?.Value?.Split(' ', StringSplitOptions.RemoveEmptyEntries) ?? Array.Empty<string>();
return scopes.Contains("orders.read") || scp.Contains("orders.read");
})
);
options.AddPolicy("orders.write", policy =>
policy.RequireAssertion(ctx =>
{
var scope = ctx.User.FindFirst("scope")?.Value ?? "";
var scopes = scope.Split(' ', StringSplitOptions.RemoveEmptyEntries);
var scp = ctx.User.FindFirst("scp")?.Value?.Split(' ', StringSplitOptions.RemoveEmptyEntries) ?? Array.Empty<string>();
return scopes.Contains("orders.write") || scp.Contains("orders.write");
})
);
});
var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();
app.MapGet("/v1/orders", [Authorize(Policy = "orders.read")] () => Results.Ok(new { ok = true }));
app.MapPost("/v1/orders", [Authorize(Policy = "orders.write")] () => Results.Ok(new { ok = true }));
app.Run();Content Security Policy (CSP) is an HTTP response header (or tag) that tells the browser which sources of content are allowed to load on your site — and blocks everything else.
Content-Security-Policy: script-src 'self' https://cdn.domain.com https://login.identityprovider.com; object-src 'none'; base-uri 'self'; frame-ancestors 'none';This means:
- Only load JavaScript from your own origin ('self'), your CDN, and your identity provider (IdP).
- Block inline
<script>tags unless explicitly allowed. - Block loading plugins (object-src 'none').
- Prevent clickjacking (frame-ancestors 'none').
Your frontend app (domain.com) is your attack surface — not your API.
If a malicious script sneaks in via a vulnerable dependency, third-party widget, or injection (e.g. stored XSS), it could:
- Steal access tokens or session cookies.
- Inject fake forms to capture credentials.
- Make unauthorized API calls to api.domain.com. A tight CSP prevents most of those by restricting where scripts, styles, images, and frames can come from
If your frontend uses:
Scripts from your app and CDN,
Fonts from Google Fonts,
Calls your backend API at https://api.domain.com,
And uses Auth0 / Azure AD for login,
then you might use:
Content-Security-Policy:
default-src 'none';
script-src 'self' https://cdn.domain.com https://cdn.auth0.com;
connect-src 'self' https://api.domain.com https://YOUR-IDP-DOMAIN;
img-src 'self' data:;
style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
font-src https://fonts.gstatic.com;
frame-ancestors 'none';
base-uri 'self';You can set it either:
In your reverse proxy / CDN / server:
add_header Content-Security-Policy "script-src 'self' https://cdn.domain.com ..." always;
Or in your app:
<meta http-equiv="Content-Security-Policy" content="script-src 'self' ...">
Use the header form whenever possible — it’s more secure and can’t be overridden by the page. credit institution providing BaaS (bank accounts, cards, payments, lending, KYC) via APIs
- Orchestration service Flow: Intent → Authorize → Capture/Settle → Notify → Reconcile
Public (prod)
https://domain.com– marketing / docs landing (no PII)https://docs.domain.com– API docs & changeloghttps://status.domain.com– uptime & incidentshttps://console.domain.com– partner/admin console (MFA required)https://auth.domain.com– OAuth2/OIDC (Authorization Server)https://api.domain.com– public API v1 (JSON over HTTPS)https://events.domain.com– webhook delivery IPs (outbound)https://sandbox.api.domain.com– public sandbox APIhttps://sandbox.auth.domain.com– sandbox IdP
- Customers & KYC/KYB Customers
- POST /customers (scope: customers.write) – create person/business
- GET /customers/{customerId} (customers.read)
- PATCH /customers/{customerId} (customers.write) – updates (addr, phone)
- POST /customers/{customerId}:close (customers.write) KYC/KYB
- POST /customers/{customerId}/kyc-intents (kyc.write) – start verification
- GET /kyc-intents/{intentId} (kyc.read) – status: pending|needs_info|verified|rejected
- POST /kyc-intents/{intentId}/documents (kyc.write; multipart) – doc upload
- GET /customers/{customerId}/screenings (kyc.read) – PEP/sanctions hits & decisions
- Accounts & products Products
- GET /products (products.read) – list product definitions (DDA, savings, wallet)
- GET /products/{productId} (products.read) Accounts
- POST /accounts (accounts.write) – open account (customerId, productId, currency)
- GET /accounts?customer_id=... (accounts.read)
- GET /accounts/{accountId} (accounts.read)
- PATCH /accounts/{accountId} (accounts.write) – freeze/unfreeze, labels
- POST /accounts/{accountId}:close (accounts.write) Balances & statements
- GET /accounts/{accountId}/balance (accounts.read) – computed from ledger GET /accounts/{accountId}/statements?from=...&to=...&format=pdf|csv (accounts.read) Beneficiaries
- POST /beneficiaries (beneficiaries.write)
- GET /beneficiaries (beneficiaries.read)
- Ledger (double-entry source of truth) Transactions
- GET /ledger/accounts/{accountId}/transactions?cursor=...&limit=... (ledger.read)
- GET /ledger/journals/{journalId} (ledger.read) Posting (internal or privileged partners)
- POST /ledger/journals (ledger.post) Reversals
- POST /ledger/journals/{journalId}:reverse (ledger.post)
{
"type":"TRANSFER",
"entries":[
{"debitAccountId":"acc_src","creditAccountId":"acc_dst","amount":{"amount":50000,"currency":"ZAR"},"valueDate":"2025-10-13","externalRef":"pm_123"}
],
"metadata":{"clientRef":"inv-8891"}
}- Payments (orchestration + rails)
- Payment Intents (generic)
- POST /payments/intents (payments.write) – create intent (source, destination, scheme, amount)
- POST /payments/intents/{id}/confirm (payments.write) – execute
- GET /payments/intents/{id} (payments.read) – state: pending|processing|succeeded|failed
- Transfers (account-to-account / internal)
- POST /transfers (payments.write) – instant book + ledger post
- GET /transfers/{id} (payments.read) Payouts (external rails)
- POST /payouts (payments.write) – to bank acct/mobile money/card
- GET /payouts/{id} (payments.read)
- POST /payouts/{id}:cancel (payments.write) (if rail supports) Collections (pull)
- POST /debits (payments.write) – create debit against mandate
- GET /debits/{id} (payments.read) Mandates
- POST /mandates (mandates.write) – create & sign mandate
- GET /mandates/{id} (mandates.read) Quotes & FX (optional)
- POST /fx/quotes (fx.read) – price a currency conversion
- POST /fx/conversions (fx.write) – book conversion
- GET /fx/conversions/{id} (fx.read) Rails metadata
- GET /rails (payments.read) – supported schemes & capabilities per country (e.g., ZA EFT, KE mobile money) Webhook events (outbound) payment.succeeded, payment.failed, transfer.posted, payout.settled, mandate.signed
- Webhooks (management)
- POST /webhooks/endpoints (webhooks.write) – register URL & secret
- GET /webhooks/endpoints (webhooks.read)
- POST /webhooks/endpoints/{id}/rotate-secret (webhooks.write)
- GET /webhooks/deliveries?endpoint_id=... (webhooks.read) Headers we send: Webhook-Id, Webhook-Timestamp, Webhook-Signature (HMAC-SHA256), Idempotency-Key Retry: exponential backoff, up to N times; replay-protection via timestamp tolerance.
- Compliance (screening, monitoring, cases) Screening (on demand/ongoing)
- POST /compliance/screenings (compliance.write) – run PEP/sanctions screening for an entity
- GET /compliance/screenings/{id} (compliance.read) Transaction Monitoring
- GET /compliance/rules (compliance.read) POST /compliance/rules (compliance.write) – create/edit rule (velocity, geo, amount patterns)
- GET /compliance/alerts?status=open (compliance.read)
- POST /compliance/alerts/{alertId}/dispositions (compliance.write) – escalate/close, add notes, attach docs Cases & reporting
- GET /compliance/cases/{caseId} (compliance.read)
- POST /compliance/reports/sar (compliance.write) – prepare SAR/STR draft (jurisdiction aware)
Many modules depend on many others (payments → core, accounts, customers; ledgers → core, accounts, customers). That grows a dense graph and slows builds.
a-guide-to-api-first-banking-and-open-finance
CockroachDB,postgres,yugabytedb Key Requirements for Databases in Fintech Here are major demands fintech systems place on their data layer:
- ACID transactions / strong consistency — for core banking, payments, ledgers.
- High throughput & low latency — for trading, payments, real-time decisioning.
- Scalability (read & write, distributed geography) — fintech systems often span regions and large user bases.
- Flexibility in schema / handling semi-structured & unstructured data — e.g., customer behaviour, logs, risk-analytics.
- Regulatory compliance, auditability, security — ledger trails, data locality, encryption. Vela - Postgres Database Platform
- Real-time analytics, time-series/historical data — market data, trading ticks, risk exposures. Because of that mix, fintech systems often adopt polyglot persistence — i.e., more than one database type depending on use-case.
Role of Finance database
- The Golden Source: Serves as the single source of truth for external regulatory, market, and financial reporting.
- Operational Backbone: Powers internal operational controls, reconciliations, and ensures smooth financial workflows.
- Critical for Safeguarding: Used as the primary data source for safeguarding customer funds and ensuring compliance with financial regulations. This means... Data must be always available, accurate, and reliable Database will be your bottleneck
In nginx, an upstream block defines a group of backend servers (e.g. your API, app, or auth service). Each server line inside tells nginx where to forward requests — by IP address + port or a UNIX socket path
upstream api_backend {
server 10.0.1.5:8080; # backend server 1 (IP:PORT)
server 10.0.1.6:8080; # backend server 2 (for load balancing)
keepalive 64;
}
Then elsewhere in your config:
location / {
proxy_pass http://api_backend;
}So when a request hits https://api.domain.com, nginx forwards it to one of those two internal servers on port 8080
There are two parts in your nginx config that work together: A server block that matches the hostname (server_name api.domain.com;) A proxy_pass directive that points to an upstream (e.g. proxy_pass http://api_backend;)
- A client (e.g. a browser or API client) sends:
GET https://api.domain.com/v1/usersnginx looks at the Host header and sees api.domain.com
- nginx finds the right server block It searches for a server block like:
server {
listen 443 ssl http2;
server_name api.domain.com;
...
}- Inside that block, there’s a location directive You’ll usually see something like:
location / {
proxy_pass http://api_backend;
proxy_set_header Host $host;
...
}- nginx looks up that upstream Earlier in the config, you defined:
upstream api_backend {
server 10.0.0.5:8080;
server 10.0.0.6:8080;
}nginx picks one of the servers and sends the HTTP request there (e.g., to http://10.0.1.5:8080/v1/users)
The proxy_pass directive tells nginx where to send a request that matches a location block.
You can point it to either:
- A named upstream block (best practice for prod):
proxy_pass http://api_backend;…whereapi_backendis defined earlier:
upstream api_backend {
server 10.0.1.5:8080;
server 10.0.1.6:8080;
}
- Or a direct URL or host:port (useful for simple one-off setups):
proxy_pass http://127.0.0.1:8080;orproxy_pass http://internal-api:8080;
# defaults to none
show dockerRepository
[info] None
dockerBaseImage
[info] openjdk:8ThisBuild / version := scala.sys.process.Process("git rev-parse HEAD").!!.trim.slice(0, 7)
//This dynamically sets your project version to the short Git commit hash of the current repository HEAD — that’s the 7-character version you often see like a1b2c3d.scala.sys.process.Process("git rev-parse HEAD").!!Runs the shell command git rev-parse HEAD inside SBT. Returns the full 40-character Git commit SHA as a string..trimRemoves any newline characters from the output..slice(0, 7)Keeps only the first 7 characters (the short SHA).
for businesses and developers, open banking provides user-consented access to user data programmatically, using APIs. Developers can now build third-party apps that connect to bank accounts seamlessly and create new user experiences
alternative to plaid is Finicity / Mastercard Open Banking (formerly Finicity)
unified API for accessing financial data across multiple banks and financial institutions, without needing to integrate with each one separately. This allows developers to build applications that can access a wide range of financial data and services with a single integration.
open investment,open finance, open pension, open loans
Aggregation Across Jurisdictions and Standards Open banking standards differ widely (e.g., UK vs. EU vs. U.S. vs. Australia). Plaid abstracts away those differences — giving fintechs a single, consistent API across regions.
A major concern of open banking is security
Apple Pay Wallet + Tokenization Service Links to your card (via banks / card networks). Generates a payment token (Device Account Number) stored securely on your iPhone or Apple Watch. When you pay, Apple sends a token — not your card number. Google Pay Wallet + Payment Service Works similarly — stores your cards (credit/debit) or account credentials. Supports both NFC tap payments and online transactions using tokens.
To install the OVHcloud CLI, you can use the following command:
curl -fsSL https://raw.githubusercontent.com/ovh/ovhcloud-cli/main/install.sh | sh
You can also run the CLI using Docker:
docker run -it --rm -v ovhcloud-cli-config-files:/config ovhcom/ovhcloud-cli login# Available commands:
account Manage your account
alldom Retrieve information and manage your AllDom services
baremetal Retrieve information and manage your Bare Metal services
cdn-dedicated Retrieve information and manage your dedicated CDN services
cloud Manage your projects and services in the Public Cloud universe (MKS, MPR, MRS, Object Storage...)
completion Generate the autocompletion script for the specified shell
config Manage your CLI configuration
dedicated-ceph Retrieve information and manage your Dedicated Ceph services
dedicated-cloud Retrieve information and manage your DedicatedCloud services
dedicated-cluster Retrieve information and manage your DedicatedCluster services
dedicated-nasha Retrieve information and manage your Dedicated NasHA services
domain-name Retrieve information and manage your domain names
domain-zone Retrieve information and manage your domain zones
email-domain Retrieve information and manage your Email Domain services
email-mxplan Retrieve information and manage your Email MXPlan services
email-pro Retrieve information and manage your EmailPro services
help Help about any command
hosting-private-database Retrieve information and manage your HostingPrivateDatabase services
iam Manage IAM resources, permissions and policies
ip Retrieve information and manage your IP services
iploadbalancing Retrieve information and manage your IP LoadBalancing services
ldp Retrieve information and manage your LDP (Logs Data Platform) services
location Retrieve information and manage your Location services
login Login to your OVHcloud account to create API credentials
nutanix Retrieve information and manage your Nutanix services
okms Retrieve information and manage your OKMS services
overthebox Retrieve information and manage your OverTheBox services
ovhcloudconnect Retrieve information and manage your OVHcloud Connect services
pack-xdsl Retrieve information and manage your PackXDSL services
sms Retrieve information and manage your SMS services
ssl Retrieve information and manage your SSL services
ssl-gateway Retrieve information and manage your SSL Gateway services
storage-netapp Retrieve information and manage your Storage NetApp services
support-tickets Retrieve information and manage your support tickets
telephony Retrieve information and manage your Telephony services
veeamcloudconnect Retrieve information and manage your VeeamCloudConnect services
veeamenterprise Retrieve information and manage your VeeamEnterprise services
version Get OVHcloud CLI version
vmwareclouddirector-backup Retrieve information and manage your VMware Cloud Director Backup services
vmwareclouddirector-organization Retrieve information and manage your VMware Cloud Director Organizations
vps Retrieve information and manage your VPS services
vrack Retrieve information and manage your vRack services
vrackservices Retrieve information and manage your vRackServices services
webhosting Retrieve information and manage your WebHosting services
xdsl Retrieve information and manage your XDSL services## Global options:
-d, --debug Activate debug mode (will log all HTTP requests details)
-f, --format string Output value according to given format (expression using gval format)
-h, --help help for ovhcloud
-e, --ignore-errors Ignore errors in API calls when it is not fatal to the execution
-i, --interactive Interactive output
-j, --json Output in JSON
-y, --yaml Output in YAML
firewalls can filter traffic based on
- ip addresses
- domain names
- protocols
- programs
- ports
- keywords
# Give the OVHcloud user (42420:42420) access to this directory
RUN chown -R 42420:42420 /workspace
if a given content asset is not in our cache for a customer’s site, we retrieve the asset from OVHcloud. Peering is a direct connection between two network providers for the purpose of exchanging traffic. Transit is when one network pays an intermediary network to carry traffic to the destination network.
Cloudflare generally exchanges most of our traffic with OVHcloud over peering links.
a dedicated reverse proxy / edge router (Nginx, Traefik) gives you TLS, routing, load-balancing, caching, security, zero-downtime upgrades, observability, and operational features that are painful, duplicative, or unsafe to reimplement in every app (http4s, Express) — especially at scale.
digital ocean hetzner fly io ovh cloud
Internet
|
Load Balancer
(LB11 - 5.39€)
|
┌──────────────┼──────────────┐
| | |
k8s-master k8s-worker-1 k8s-worker-2
(CX21-5.83€) (CX21-5.83€) (CX21-5.83€)
| | |
└──────────────┼──────────────┘
Private Network
(10.0.0.0/16)https://api.us.ovhcloud.com/ and https://eu.api.ovh.com/
Public-facing: /authorize, /token, /userinfo, /jwks.json (must be reachable by users/clients)
Open banking refers to the exchange of services and data between financial institutions such as banks and third-party providers
PSD2 is legislation designed to force service providers to improve customer authentication and security processes
In general, open banking means customers can gain access to new financial products and services from regulated third-party providers. This is made possible by banks who built APIs that follow PSD2 standards and third-party providers who get licences to connect to them. The PSD2 regulation mandated banks to provide free access to their API
Open banking allows more developers and businesses to build new FinTech services that compete with large retail banks. Competitive markets are the perfect environment for innovation, which ensures customers' needs are met to the highest level by forcing competitors to offer the best product at the best price. And the list of open banking innovations is endless
Open Finance is an extension of open banking. To reiterate, open banking refers to regulated websites and apps that can access transaction data from bank accounts and payment services. Open Finance is the next step and involves the use of open APIs that enable third-party developers to build applications and services for a wide variety of financial institutions. These financial institutions include mortgages, savings, pensions, insurance, and consumer credit
Open Finance will enable customers to consent to these third-party providers accessing their payment account information, or making online payments on their behalf.
Open Finance makes it possible for a trusted third party to access wider financial data, such as tax, insurance, and pensions. This access to data will make it easier for financial institutions to offer products and services which have been individually tailored to meet the requirements of a specific customer. Open Finance APIs will allow businesses and consumers to seek out and discover better deals from other providers, as well as other ways to minimise or reduce current payments.
Open Finance will also have an effect on Direct Debit payments, allowing Direct Debit users to save or combine payments. They will also be able to monitor exactly how much is being paid on their subscriptions
An exciting development for online shopping fans is the payment initiation services that Open Finance will provide. They will allow online shoppers to make direct payments from their bank accounts without entering their credit or debit card details each time. This also has huge potential for business-to-business payments
The lending industry is one of the most stagnant business sectors in the market. Third-party lenders must evaluate applicants’ risk profiles and financial behaviour to determine their creditworthiness. This is done in a slow, manual and biased manner or by employing algorithms that are often too simplistic in their analysis
Open Finance solves this issue because it allows lenders to access data from different areas of an applicant’s life. From taxes to spending habits, lenders can tap into data and information they previously were oblivious to
Just as Open Finance helps lenders, it also helps consumers. Open Finance will further evolve personal finance management (PFM) apps and give people with average to low financial literacy the tools they need to make informed decisions. Logging on to their app will be enough to oversee and manage all the financial aspects of their lives
One of open banking’s main advantages is the personalisation of banking products and services. By giving consent to share their data, consumers allow businesses to tailor their offerings based on their specific needs. Open Finance can improve on this. Open Finance can allow businesses from different sectors to collaborate and create packaged offerings for their customers. Opening up access to a customer’s financial footprint can create unlimited opportunities, from understanding the interaction between tax, insurance, and loans to develop offers based on real trends and relationships.
AISPs act on behalf of the bank to access customer information. They are authorised to view bank account information, but cannot initiate payments or transfers. Credit bureaus, for example, may use AISPs to check a customer’s credit history and creditworthiness. PISPs, meanwhile, act on a consumer’s behalf to initiate payments. A PISP allows you to carry out online payments without the need for credit or debit card details.
With open banking, regulated TPPs are permitted access to your bank account data and can initiate payments. This access to your account, however, is only granted with your consent, which can be withdrawn at any time and keeps you in control. Open banking can be used with any payment account that is accessible online. This includes but is not limited to, current accounts, credit cards and even some savings accounts.
Open banking, by way of TPPs, offers users the following feature:
- Financial management
- Access to all account information in one place
- Tools for managing debt
- Apps for making bank payments via TPP
- Tools for budgeting
An authorised AISP can access a user’s bank account data via their financial institution, but this only happens when the user provides explicit consent. This access is, however, defined as “read-only”, which means that they can only see the information but cannot access the account. Therefore, it is not possible for the AISP to, for example, move money from that account
AISPs access financial data — provided that the user has consented to share that information — and use it to offer personalised and innovative financial products and services. From savings insights to ethical investment, AISPs use advanced machine learning algorithms and data analytics to offer recommendations that are suited to the specific needs of a particular user.
A Payment Initiation Service Provider (PISP) is able to access read-only data from a bank account, and they are also authorised to initiate payments on a customer’s behalf. PISPs can therefore be used to make payments directly from a bank account, removing the need for a debit or credit card.
Build a unified payment platform for businesses and individuals
GET /cards
GET /cards/{card_id}
POST /cards/issue
POST /cards/{card_id}/activate
POST /cards/{card_id}/block
POST /cards/{card_id}/unblock
PATCH /cards/{card_id}/limits
PATCH /cards/{card_id}/controls
GET /cards/{card_id}/transactions
POST /wallets
GET /wallets
GET /wallets/{walletId}
PUT /wallets/{walletId}
DELETE /wallets/{walletId}
GET /wallets/{walletId}/balances
GET /wallets/{walletId}/transactions
GET /transactions/{transactionId}
POST /trades/quote
POST /trades/buy
POST /trades/sell
GET /trades/{tradeId}
GET /trades
POST /crypto/deposit
POST /crypto/withdraw
GET /crypto/addresses/{walletId}
POST /fiat/deposit
POST /fiat/withdraw
GET /fiat/accounts
POST /plaid/link-token
POST /plaid/exchange-token
GET /plaid/accounts
DELETE /plaid/accounts/{accountId}
#Plaid Webhooks
POST /webhooks/plaid
#
POST /admin/auth/login
POST /admin/auth/logout
GET /admin/auth/session
GET /admin/users
GET /admin/users/{userId}
PUT /admin/users/{userId}
POST /admin/users/{userId}/lock
POST /admin/users/{userId}/suspend
POST /admin/users/{userId}/unlock
GET /admin/users/search
GET /admin/users?status=&country=&kycLevel=&dateFrom=&dateTo=
GET /admin/kyc/pending
GET /admin/kyc/{userId}
POST /admin/kyc/{userId}/approve
POST /admin/kyc/{userId}/reject
POST /admin/kyc/{userId}/resubmit
POST /admin/kyc/{userId}/override
GET /admin/wallets
GET /admin/wallets/{walletId}
GET /admin/wallets/{walletId}/balances
GET /admin/wallets/{walletId}/transactions
GET /admin/transactions
GET /admin/transactions/{transactionId}
POST /admin/compliance/flag-user
POST /admin/compliance/unflag-user
GET /admin/compliance/reports
GET /admin/roles
POST /admin/roles
PUT /admin/roles/{roleId}
DELETE /admin/roles/{roleId}
GET /admin/permissions
POST /admin/users/{userId}/roles
# KYC & Compliance (ZeroHash Integration)
POST /kyc/start
POST /kyc/documents
POST /kyc/selfie
GET /kyc/status
GET /kyc/result
POST /kyc/resubmit
GET /kiosks
GET /kiosks/nearby?lat=&lng=
GET /kiosks/{kioskId}
POST /kiosks/{kioskId}/deposit
POST /kiosks/{kioskId}/withdraw
GET /kiosks/{kioskId}/transactions