When the build comes to the QA team, what are the parameters to be taken
for consideration to reject the build upfront without committing for
testing ?

Answer1:
Agree with R&D a set of tests that if one fails you can reject the build.
I usually have some build verification tests that just make sure the build is stable and the major functionality is working.
Then if one test fails you can reject the build.

Answer2:
The only way to legitimately reject a build is if the entrance
criteria have not been met. That means that the entrance criteria to
the test phase have been defined and agreed upon up front. This
should be standard for all builds for all products. Entrance
criteria could include:
- Turn-over documentation is complete
- All unit testing has been successfully completed and U/T cases are
documented in turn-over
- All expected software components have been turned-over (staged)
- All walkthroughs and inspections are complete
- Change requests have been updated to correct status
- Configuration Management and build information is provided, and
correct, in turn-over
The only way we could really reject a build without any testing,
would be a failure of the turn-over procedure. There may, but
shouldn't be, politics involved. The only way the test phase can
proceed is for the test team to have all components required to
perform successful testing. You will have to define entrance (and
exit) criteria for each phase of the SDLC. This is an effort to be
taken together by the whole development team. Developments entrance
criteria would include signed requirements, HLD doc, etc. Having
this criteria pre-established sets everyone up for success

Answer3:
The primary reason to reject a build is that it is untestable, or if
the testing would be considered invalid.
For example, suppose someone gave you a "bad build" in which several of
the wrong files had been loaded. Once you know it contains the wrong
versions, most groups think there is no point continuing testing of
that build.
Every reason for rejecting a build beyond this is reached by agreement.
For example, if you set a build verification test and the program fails
it, the agreement in your company might be to reject the program from
testing. Some BVTs are designed to include relatively few tests, and
those of core functionality. Failure of any of these tests might
reflect fundamental instability. However, several test groups include a
lot of additional tests, and failure of these might not be grounds for
rejecting a build.
In some companies, there are firm entry criteria to testing. Many
companies pay lipservice to entry criteria but start testing the code
whether the entry criteria are met or not. Neither of these is right or
wrong--it's the culture of the company. Be sure of your corporate
culture before rejecting a build.

Answer4:
Generally a company would have set some sort of minimum goals/criteria that a build needs to satisfy - if it satisfies this - it can be accepted else it has to be rejected
For eg.
Nil - high priority bugs
2 - Medium Priority bugs
Sanity test or Minimum acceptance and Basic acceptance should pass
The reasons for the new build - say a change to a specific case - this should pass
Not able to proceed - non - testability or even some more which is in relation to the new build or the product
If the above criterias don't pass then the build could be rejected.