Open with the business problem, not your preferred technology. What kind of user will use the system, how many times a day, fintech app development and how is the job done today? An experienced team who knows what you are trying to achieve will suggest an alternative that costs less; one who only sees the requirements as given will price exactly what you asked for.
Define what is included as short scenarios: a walk through each important path. Equally important, state explicitly what you are not building. A written out-of-scope list prevents more disagreement during acceptance than almost anything else in the document. Mark too which decisions are settled and which are still under discussion — the difference changes the price, and concealing the open questions only hurts you.
Write down the hard constraints. These include the platforms and livewire development services involved, the data you have and where it lives, regulatory obligations, traffic expectations, target platforms and infrastructure that is already decided. If there is a hard date, say why: a good team can often resequence the work to meet it, but only if they know it exists.
Write down what completion means feature by feature. Clear acceptance criteria do not need special syntax: a plain-language note describing the expected behaviour is enough. That one addition shortens the sign-off process considerably and removes most late-stage disagreement.
Finally, state what you want in the response. Require a breakdown by feature or module, a written list of assumptions, the risks the team sees and an optimistic and a pessimistic figure. Read a wide range as information, not evasion: it normally identifies where your description is thin. From there tighten that section and ask for a new estimate — the next version is far closer to reality.