01 · Controlled agreement record
Negotiation, approval, amendment, and reporting behavior stayed connected to the same agreement.
Customer work · Banking and financial services
An FX document platform connected negotiation, approvals, bulk updates, and reporting
Financial-market participants needed a controlled way to create, negotiate, approve, update, and report on pre-trade FX agreements. BluePi designed a platform supporting multiple agreement types, configurable workflows, offline participants, bulk changes, risk-system integration, and GraphQL reporting.
Pre-trade FX document management platform
Pre-trade FX agreements carried legal terms, trading conditions, permitted products, participant capacity, and relationships across financial participants. BluePi built a platform for agreement types, participants, signatories, free-text legal terms, negotiation, approvals, offline participants, bulk updates, risk integration, and GraphQL reporting.
02 · Configurable approval paths
Approval flows and new document types could change without creating a separate application flow.
03 · Connected risk reporting
Bulk updates, risk-management integration, GraphQL reporting, security, and auditability shared the product boundary.
A regulated workflow from terms to reporting
BluePi implemented the platform with Spring, Java, React, CKEditor, PostgreSQL, Redis, GraphQL, Kafka, Kubernetes, and AWS. The product path represented agreement types, parties, signatories, legal text, negotiation states, approvals, offline participation, bulk changes, risk integration, and reporting, with a non-functional design target of 100 transactions per second.
Keep the document as the controlled record
Negotiation, approval, amendment, and reporting behavior remained connected to the same agreement.
Make workflow configurable
Approval paths and new document types could change without creating a separate application flow.
Support connected operations
Bulk updates, risk integration, reporting, security, and auditability shared the product boundary.
Where this pattern fits
This case is relevant when regulated agreement operations span several participants, document types, approval paths, and connected financial systems.
Working-session promptsQuestions that define the delivery boundary
Use these prompts to decide whether the case fits your operating problem and what a first deployment should prove.
- Which document types, legal terms, products, participants, and signatory structures must the platform represent?
- How should negotiation and approval work when some participants are offline?
- Which risk-management and reporting integrations require document and workflow state?
- Which bulk actions must retain the same approval, security, and audit controls as individual changes?
- What workload establishes the required transaction-rate and response-time targets?
A practical first step
A first engagement can map one agreement type, its participants, negotiation states, approval path, risk integration, and reporting requirements, then implement one end-to-end controlled document flow.
Case details
Open a section to review the customer problem, implementation, business change, and architecture.
01Starting point
Pre-trade agreements recorded legal terms, trading conditions, permitted products, and participant capacity. Regular amendments required documents to be updated and signed again. Managing that work manually created delays and increased financial and regulatory exposure.
02What BluePi built
BluePi built one application for creating, negotiating, approving, updating, and reporting on pre-trade agreements across financial products and asset classes.
- Multiple document types
- Flexible participant and signatory structures
- In-system negotiation of free-text legal terms
- Configurable approval workflows
- Offline-participant support
- Bulk document updates
- Risk-management integrations
- GraphQL reporting and query builder
- Auditability and security controls
- Configurable addition of new document types
03Application components
React and CKEditor supported the user experience. Spring and Java handled application behavior. PostgreSQL, Redis, Kafka, and GraphQL supported controlled state, messaging, and reporting, with Kubernetes on AWS as the documented runtime stack.
04Performance requirement
The platform was designed to a non-functional target of 100 transactions per second.
05Operating change
Document operations moved into one application path, allowing negotiation, approval, amendment, reporting, and integration behavior to remain connected to the same controlled document record.