Fintechs
Embed payment services in your product with Tractial. Connect payment accounts, IBANs, incoming and outgoing flows, user verification and reporting to your own experience.
Define the model that fits your project: API integration, grey label, white label or payment-institution agent status, according to the services and responsibilities envisaged.
- Your product
- Onboarding
- Account and IBAN
- Payments and tracking
User experience · KYC / KYB · According to the validated model · Flows, statuses, reporting
In brief
Your product carries the experience. The infrastructure executes the payments.
Fintech infrastructure connects a product’s financial functions to a payment provider’s services. It makes it possible to embed onboarding, accounts, payments and the data needed to track operations.
Your team focuses on uses, distribution and interfaces. The financial perimeter is built with Tractial, taking into account users, flows, countries and how responsibilities are split. Technical integration and the choice of regulatory status are two linked, but distinct, decisions.
IdentifyOpenReceivePayTrack
From product to flows
Start from a concrete use to define your offering
The right starting point is the user journey: what they want to receive, pay or track in your application. From that use, teams determine the services needed and each party’s role.
Account embedded in a B2B product
A business accesses a payment account and its movements from the tool it already uses. The account, its holder and the functions are defined in the chosen model.
Payment-management solution
A product ties settlements to invoices, files or services. Business references make it possible to track flows and handle situations that need intervention.
Financial-services platform
A fintech assembles several building blocks into a coherent journey. The offering can start from a precise need before being extended, after the new perimeter has been validated.
Financial architecture
A visible journey. Identified movements.
The interface shows a simple action, such as receiving a settlement or paying a beneficiary. Behind the scenes, each operation must be tied to the right user, the account concerned and a reference the teams can use.
PayerPayment accountBeneficiaryInitiates a settlement · Holder and allocation defined · Receives an authorised payment
Teaching diagram: funds do not necessarily pass through an account belonging to the fintech.
Identify
Associate the flow with its user and its business object.
Control
Apply the validations and checks planned for the operation.
Execute
Process the operation within the contracted perimeter.
Return
Transmit the statuses and data the product needs.
Embedded experience
Tie financial actions to the screens of your product
The account, the payment and its status must remain understandable in the user journey. The examples below illustrate that continuity without constituting an interface contract.
Support account opening
The product collects the information planned for onboarding, shows file progress and returns requests for additional information. Service activation depends on the applicable checks and validations.
Fictional data.
- Profile
- Example company
- File
- Under review
- Account
- Conditional activation
- Next step
- Additional information requested
Associate a settlement with its user
Available data makes it possible to tie an incoming payment to an account and a business reference. Unidentified cases must be something the relevant teams can handle.
Fictional data.
- Business reference
- DOS-1042
- Amount
- €2,480.00
- Movement
- Received
- Reconciliation
- To confirm
Embed payment to a beneficiary
The user prepares an operation from the fintech. The journey takes into account their rights, beneficiary data, required authorisations and the processing result.
Fictional data.
- Beneficiary
- Example supplier
- Amount
- €1,240.00
- Authorisation
- Required
- Operation
- To validate
Return an operational view
Movements, references and statuses feed tracking in the product. The fintech can organise its control and support screens around the information actually available.
Fictional data.
- Account
- ACT-00042
- Last movement
- Outgoing payment
- Status
- Executed
- Reference
- OP-00982
Building blocks
Assemble the perimeter useful to your fintech
An integration can cover a single function or several coordinated building blocks. Each feature is selected according to the user need and the conditions of implementation.
Embed an account and the information needed to use it, according to the contracted holder and model.
Associate an IBAN when the journey needs to receive transfers and identify the associated flows.
Tie received settlements to the accounts, users and business references concerned.
Connect beneficiary payments to the journey’s authorisation and control rules.
Assess card collection if this payment method matches the use case and the applicable conditions.
Refunds
Plan for their tracking and their tie-back to the original operation within the chosen perimeter.
Connect person and company checks to the onboarding steps.
Balances and movements
Return the data available to track the account and operations.
Reconciliation
Associate financial references and business objects; isolate ambiguous cases for handling.
Reporting
Provide teams with the data planned for financial and operational tracking and for support.
Synchronise financial functions with the product’s screens and processing.
Exception handling
Plan for handling incomplete files, rejected operations and requests for additional information.
Onboarding
Embed verification in the user experience
The opening journey includes the information and checks needed for the envisaged services. For an individual, it may fall under KYC; for a company, under KYB, including identification of beneficial owners when required.
The fintech must provide a clear progression, understandable requests for additional information, and a distinct state between a file in progress, activated services and a refused file. The initial verification sits within monitoring adapted throughout the relationship.
Profile
Identify the type of user and the service requested.
Information
Collect the required data and documents.
Checks
Carry out the controls according to the chosen arrangement.
Review
Handle validation, additional information or refusal.
Activation
Open the authorised functions after validation.
Monitoring
Manage later updates and checks.
Embedding a KYC/KYB module is not, on its own, enough to make an offering compliant.
Launch model
Choose integration and responsibilities together
API, grey label and white label describe the integration and presentation of the services. Agent status describes a regulatory framework for providing them. A customised interface therefore does not, on its own, determine the fintech’s status.
API integration
You keep your screens and connect the financial functions selected. How the services are provided and the information intended for users are defined in the project.
Grey label or white label
The experience uses embedded building blocks adapted to the partner’s brand. The degree of customisation and the provider’s visibility are scoped contractually.
Payment institution agent
The fintech can carry out the activities provided for by its mandate on behalf of Tractial, within the limits of the licence and after the applicable formalities.
Grey label and agent
Compare launch effort and the level of involvement
Grey label can make launch preparation easier by reusing existing journeys and infrastructure. In return, the fintech must respect the agreed processes, disclosures and customisation limits. Agent status opens another level of involvement, with a mandate, a control arrangement and dedicated formalities.
| Dimension | Grey label / white label | Payment institution agent |
|---|---|---|
| Role | Services operated in the model defined with Tractial; experience carried by the fintech. | Activities carried out on behalf of Tractial within the mandate’s perimeter. |
| Journey and brand | Customisation according to the building blocks selected and the mandatory disclosures. | Journey defined by the mandate and the information duties on agent status. |
| Launch preparation | Reuse of existing journeys that can reduce some development. | Preparation of the application file, controls and the agent’s organisation. |
| Constraints | Respect for the agreed journeys, activation rules and technical limits. | Fitness and propriety, competence, controls, training and applicable registration. |
| Evolution | New features and customisation to be validated. | Evolution of the mandate and perimeter to be validated; no own licence is conferred. |
Regulatory framework
Agent status is prepared before the activities are carried out
An agent provides the services for which it is mandated, in the name and on behalf of the payment institution. Tractial remains responsible for the services provided by its agent; that responsibility comes with a supervision arrangement.
The project specifies the activities, users, countries, flows and tasks entrusted to the fintech. Conditions of fitness and propriety and of competence, internal control and the anti-money laundering and counter-terrorist financing arrangement are examined within the applicable framework.
When registration with the ACPR is required, agent activities start only after the corresponding entry in the register. Public communication must identify the capacity as agent. The agent does not itself become a payment institution.
Project organisation
Split the tasks without blurring the responsibilities
The project must specify responsibilities from the outset: who provides the service, who presents the terms, who collects the information and who handles user requests. This organisation depends on the chosen model.
Your fintech
- Define the uses, interfaces and product distribution.
- Describe the customer base, countries and expected flows.
- Embed the agreed journeys and information.
- Organise support and escalations according to the contractual split.
- Carry out the tasks that belong to its role and, where applicable, to its mandate.
Tractial
- Qualify the services that fall within its Payment Institution perimeter.
- Define with the partner the financial journeys and the required controls.
- Provide the selected building blocks and the available operational information.
- Operate the agreed services and supervise the activities entrusted to agents.
- Scope responsibilities, activation and the tracking of services.
API and Payment.net
Connect your product to a dedicated financial layer
The integration ties your product’s objects to the accounts and operations tracked in the payment infrastructure. The same reference must make it possible to retrieve the context of an action in each party’s systems.
Scoping specifies the available APIs, authentication, events, errors, environments and processing rules. Access to documentation and the test environment comes in the project qualification journey.
Your product
- User interfaces
- Business references
- Rights and validations
- Support and tracking
API and webhooks
Tractial / Payment.net
- Accounts and IBANs
- Operations and statuses
- KYC / KYB journeys
- Reporting data
Exchanges must handle duplicates, delays and events received in a different order.
From pilot to production
Advance through validated steps
A pilot is used to test the user journey, the flows and the operational organisation. Its success does not replace the validations needed to go to production or to extend the services.
Qualify
Describe the product, users, flows and countries.
Scope
Choose the building blocks, the model and the split of tasks.
Contract
Formalise responsibilities and activation conditions.
Integrate
Connect the interfaces and test the nominal cases and the exceptions.
Pilot
Observe the journey, operations and support handling.
Deploy
Activate the validated perimeter, then organise ongoing monitoring.
Product trajectory
Evolve the offering according to actual needs
A fintech can start with a limited perimeter, then add features or assess a different role. Moving to an agent model or to an own licence is a distinct project: it requires its own analyses, resources and validations.
A change of provider or model must also take into account accounts, data, consents, contracts and service continuity. The reuse of IBANs or user files must be verified; it cannot be assumed.
MVP
Validate a use and the first journeys on a controlled perimeter.
V1
Widen the functions and make support, controls and reporting more reliable.
Deployment
Assess new segments, countries or roles before activating them.
Services and coverage
Define precisely what your offering includes
A project’s coverage depends on the services, users, countries and payment circuits concerned. Embedding accounts or payments does not automatically include credit, investment or digital-asset services.
A payment account must be presented according to its functions and its legal framework. How funds are safeguarded, the terms of use and the identity of the provider are explained in the applicable documentation. Additional services are subject to a dedicated qualification.
FAQ
Do you need your own licence to launch a fintech?
It depends on the activities actually carried out. A product can rely on a licensed provider or act as an agent within an appropriate framework. Using an API or a white label is not enough to determine the required status.
What is the difference between API, grey label and agent status?
The API is a technical means of integration. Grey label describes an experience carried by the partner, with the provider’s visibility defined according to applicable duties. Agent status frames the carrying-out of services on behalf of a payment institution.
Does grey label allow a faster launch?
Reusing existing building blocks and journeys can reduce some development. It also means respecting the agreed processes and limits. The timeframe depends on the project and the required validations.
Can the fintech use only its own brand?
The commercial presentation is defined with the teams, but it must keep the mandatory information on the provider and, where applicable, on agent status. Branding does not change regulatory responsibilities.
Can a payment account and an IBAN be embedded?
These building blocks can be assessed with Tractial. Their implementation depends in particular on the holders, the services selected, onboarding and the countries concerned.
What is the difference between a payment account and a bank account?
The payment account is used for the operations provided for in the provider’s perimeter. It must not be presented as a classic bank account with functions that are not included in the offering.
Who carries out KYC and KYB checks?
Collection, verification, review and monitoring tasks are split in the operational and contractual model. An embedded journey does not relieve any party of the duties attached to its role.
When can an agent start its activities?
After the mandate conditions and the required formalities have been completed, including registration in the applicable register. Signing a contract or a commercial diagnostic is not, on its own, authorisation to operate.
Can the services be offered in several countries?
Coverage is examined for the countries, users and services concerned. Applicable formalities, including the use of agents in the European Economic Area, must be taken into account.
Are documentation and the sandbox open to the public?
Access to technical documentation and the test environment is organised after project qualification, according to the envisaged perimeter. The teams specify the accessible functions and the terms of use.
Can the model or provider be changed later?
An evolution can be assessed. It requires checking the contractual, operational and technical impacts, in particular on accounts, IBANs, data and user journeys.
How do you start with Tractial?
Present the use, the customer base, the countries, incoming and outgoing flows, envisaged volumes and the functions wanted. These elements make it possible to define the perimeter to assess with the teams.
Go further on the building blocks of your project
Payment accounts and IBANs
Embed an account and the information needed to use it, according to the contracted holder and model.
See the pageIncoming and outgoing payments
Tie received settlements to the accounts, users and business references concerned.
See the pageKYC, KYB and compliance
Connect person and company checks to the onboarding steps.
See the pageWhite label and grey label
The experience uses embedded building blocks adapted to the partner’s brand. The degree of customisation and the provider’s visibility are scoped contractually.
See the pagePayment institution agent
The fintech can carry out the activities provided for by its mandate on behalf of Tractial, within the limits of the licence and after the applicable formalities.
See the pageAPI and integrations
Synchronise financial functions with the product’s screens and processing.
See the pageYour fintech and Tractial
Let’s build your product’s financial journey
Show us your users, your flows and the functions you want to embed. Our teams will assess with you the building blocks, the operating model and the framework that fit your project.
Payment institution licensed by the ACPR, CIB 16748. Services are offered subject to eligibility, compliance validation, contracting, technical availability and the applicable regulatory framework.